mock.patch没生效最常见的原因是patch位置错误，应patch函数被使用处而非定义处；mock.return_value适用于固定返回值，side_effect适合异常、多响应或动态逻辑；mock轻量，magicmock支持魔术方法；patch.object更安全，依赖对象而非字符串路径。
mock.patch 为什么没生效？
最常见的原因是 patch 的位置不对——不是目标函数「在哪里定义」，而是「在哪里被使用」。比如你在 utils.py 里定义了 requests.get，但在 service.py 里调用了它，那就要在 service.py 的命名空间里 patch，而不是 utils.py。
- 用
@mock.patch('service.requests.get')，不是@mock.patch('requests.get') - 如果用上下文管理器，同样写
with mock.patch('service.requests.get'): - 模块级 patch 要确保测试导入的是被 patch 的模块，而非直接导入函数（如避免
from requests import get）
mock.return_value 和 mock.side_effect 怎么选？
前者适合固定返回值，后者更适合模拟异常、多次调用不同响应或带逻辑的返回。
-
mock.return_value = {'status': 'ok'}：所有调用都返回这个字典 -
mock.side_effect = [ValueError('timeout'), {'status': 'ok'}]：第一次抛异常，第二次返回字典 -
mock.side_effect = lambda url: {'url': url, 'data': 'mocked'}：按输入动态生成返回 - 注意：设了
side_effect后，return_value会被忽略
mock.Mock() 和 mock.MagicMock() 有啥区别？
绝大多数时候该用 Mock；只有当你需要 mock 对象支持魔术方法（比如 len()、iter()、__str__）时，才用 Mock 不够，得上 Mock 或 Mock。
- 想 mock 一个类并让它能被
for item in obj:遍历？用Mock - 想 mock 一个对象，又希望
str(obj)不报TypeError？用Mock - 普通函数、方法、简单对象，
Mock足够，更轻量，行为更可预测 -
Mock会自动实现一堆魔术方法，有时反而掩盖了真实调用缺失的问题
patch.object 什么时候比 patch 更安全？
当你明确知道要 patch 的是某个类/模块的特定属性，并且不依赖字符串路径时，patch.object 更稳定、更易重构。
立即学习“Python免费学习笔记（深入）”；
-
@patch.object(MyClass, 'fetch_data', return_value='mocked')比@patch('my_module.MyClass.fetch_data')更可靠 - 重命名类或方法时，IDE 能自动更新
patch.object的引用，但字符串路径不会变 - 适用于单元测试中已 import 的对象，避免拼错模块路径导致 silent failure
- 注意：传入的是对象本身，不是字符串；不能用于 patch 尚未 import 的模块
最常被忽略的其实是 patch 的作用域和生命周期——mock 对象只在 patch 生效范围内存在，一旦退出上下文或装饰器作用域，原始行为立刻恢复。别指望在一个 test 方法里 patch 了，然后在另一个 test 里还有效。
