直接读取 mock 对象的 call_count 属性即可获取调用次数，它由 mocker.patch() 或 mocker.spy() 创建后立即可用，无需额外配置；需确保断言在 patch/spy 作用域内且目标代码已执行。
pytest-mock里怎么获取mock对象的调用次数
直接看 call_count 属性，它就是专为这个设计的。只要用 mocker.patch() 或 mocker.spy() 创建了 mock，就能立刻读取——不需要额外配置或启动计数器。
常见错误是误以为要手动初始化计数器，或者在 patch 作用域外访问 call_count 导致值为 0（比如 patch 在 fixture 里但断言写在测试函数外面）。
-
mocker.patch('module.func')返回的 mock 对象有call_count -
mocker.spy(obj, 'method')返回的 spy 对象同样支持call_count - 确保断言语句在被 patch/spy 的代码实际执行之后，且仍在同一作用域内
spy 和 patch 在调用计数上的关键区别
mocker.spy() 是“监听真实函数”，调用会真正执行，同时记录行为；mocker.patch() 是“替换函数”，原函数根本不会运行。选哪个取决于你是否需要验证副作用或返回值是否按预期发生。
比如你要确认某个日志函数被调用了 2 次，且每次参数不同，又得保证日志确实打出去了（比如触发了文件写入），那就必须用 spy；如果只是校验逻辑分支是否触发、不关心实际执行，patch 更轻量、更安全。
-
spy：适合验证“真实调用是否发生 + 参数 + 次数”，但可能引发副作用（如网络请求、磁盘 IO） -
patch：适合纯行为验证，隔离性强，call_count更稳定 - 对类方法 spy 时，注意是 spy 实例方法还是类方法——
mocker.spy(MyClass, 'method')监听所有实例，mocker.spy(obj, 'method')只监听该实例
assert_called() 系列方法和 call_count 怎么配合用
call_count 是数值，灵活但需手动比对；assert_called_once()、assert_called_with() 这些是断言快捷方式，语义明确但覆盖场景有限。实际中建议优先用 call_count 做基础校验，再用 call_args_list 查具体参数。
容易踩的坑是混淆 assert_called_once() 和 assert_called_once_with(...)：前者只检查次数为 1，后者还校验最后一次调用的参数——如果调用 2 次但只有最后一次参数匹配，后者会失败，而前者不会报错。
- 查是否调用 ≥1 次：
assert mock.call_count > 0 - 查是否恰好 3 次：
assert mock.call_count == 3 - 查每次调用的参数：
mock.call_args_list[0] == call('a')（需先from unittest.mock import call） - 避免过度依赖
assert_called_once_with()，它不反映调用历史全貌
为什么有时候 call_count 始终是 0
最常见原因是 patch 路径写错了——不是目标函数当前被导入的位置，而是它“被使用的位置”。比如 utils.py 定义了 send_email()，但测试的是 service.py 里导入并调用它的代码，那就要 patch service.send_email，而不是 utils.send_email。
另一个隐蔽问题是 patch 作用域太窄：比如在 fixture 里 patch，但没 return mock 对象，或测试函数没接收该 fixture；或者用了 autouse=True fixture 却忘了在测试函数签名里声明依赖。
- 用
print(mock._mock_name)或mock.called快速确认 mock 是否被触达 - 临时加
mock.side_effect = lambda *a, **k: print("called!")看是否真进来了 - 对模块级函数，优先 patch “测试文件里 import 的那个名字”，不是定义处
call_count 是否非零，先确认 mock 对象本身有没有被传进去、有没有被正确引用——很多“调用没被统计”的问题，根源是 mock 根本没生效。Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
