mock.open抛出oserror未生效，是因为mock对象默认不支持上下文管理协议，需手动添加__enter__/__exit__或使用mock_open(side_effect=oserror)。
mock.open 抛出 OSError 时为什么没生效
直接 patch builtins.open 并让它 raise OSError，却没触发被测代码的异常处理逻辑？常见原因是：被测函数内部用了 with open(...)，而 mock 对象默认不支持上下文管理协议。必须手动给 mock 对象加上 __enter__ 和 __exit__ 方法，或者更稳妥地用 mock_open 配合 side_effect。
实操建议：
- 用
unittest.mock.mock_open创建基础 mock，再通过side_effect指定异常：比如mock_open(side_effect=OSError("Permission denied")) - 如果被测代码在
open()后立刻调用.read()，需确保 mock 的返回对象（即文件句柄）也抛异常：可链式设置mock_file = Mock(); mock_file.read.side_effect = OSError - 注意 Python 版本差异：
builtins.open在 Python 2 是__builtin__.open，测试前先确认运行环境
测试 FileNotFoundError 场景要绕过 os.path.exists 吗
当被测函数先调用 os.path.exists(path) 再尝试 open(path)，只 mock open 不足以覆盖「路径存在但读取失败」和「路径根本不存在」两种分支。这时必须同时控制 os.path.exists 的返回值。
实操建议：
- 用
@patch("os.path.exists")和@patch("builtins.open")双重 patch，前者返回True或False控制路径可见性 - 若被测代码还调用了
os.makedirs或Path.mkdir，也要一并 patch，避免真实目录被创建干扰测试隔离性 - 不要依赖真实文件系统路径（如
/tmp/test.txt），哪怕加了tearDown清理，也容易因权限或并发导致偶发失败
如何让 StringIO 也抛 IO 异常
有些代码用 StringIO 做内存文件模拟，但 StringIO.read() 默认不会抛 IOError —— 它继承自 IOBase，但行为是纯内存的。想让它模拟磁盘 IO 失败，得手动包装或替换。
实操建议：
- 别直接 patch
StringIO类，而是 patch 被测模块中实际 import 的位置，比如@patch("mymodule.StringIO") - 用自定义类继承
StringIO，重写read方法：例如def read(self, *args): raise OSError("Disk full") - 更轻量的做法：用
Mock替代StringIO实例，并设side_effect，但要注意它不支持.seek()等真实方法，需按需补全
pytest 中用 pytest-mock 插件更简洁吗
是的，pytest-mock 提供 mocker fixture，自动处理 patch 生命周期，不用手动 start/stop 或写嵌套 @patch。但它底层仍是 unittest.mock，语法差异小，迁移成本低。
实操建议：
- 在测试函数参数里加
mocker，然后mocker.patch("builtins.open", side_effect=PermissionError) - 对多层嵌套调用（如
json.load(open(...))），优先 patchjson.load本身，比层层 mockopen更直接 - 注意
mocker的作用域默认是函数级；若需模块级生效，改用mocker.patch(..., scope="module")
IO 异常的边界往往藏在嵌套调用和路径预检里，光 mock open 不够，得顺着被测代码的控制流，一层层看它到底在哪儿检查、哪儿打开、哪儿读写。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
