私有方法不能被直接Mock，必须Mock其调用路径；单下划线方法需patch类名+方法名，双下划线方法需处理name mangling后的名称，且应优先重构为可测试设计。
私有方法不能被直接Mock，必须Mock其调用路径
Python 的私有方法（以 _ 或 __ 开头）本质上只是命名约定，没有真正的访问限制。但 unittest.mock.patch 无法直接 patch 一个未被导入或未被绑定到实例上的私有方法——因为 mock 的目标必须是“可定位的对象”，比如模块中定义的函数、类属性、实例方法绑定后的对象。如果你尝试 @patch('mymodule.MyClass._private_method')，而该方法只在实例内部被调用（如 self._private_method()），那 patch 失败是因为它实际调用的是实例上的绑定方法，不是模块级函数。
正确做法是 patch 实例方法本身，即 patch MyClass._private_method（注意：不是字符串路径中的 self._private_method，而是类名 + 方法名）。
- 确保 patch 目标是
MyClass._private_method，不是myinstance._private_method - patch 必须在测试运行时生效，推荐用
@patch装饰器或with patch(...)上下文管理器 - 如果方法用了双下划线（
__），Python 会触发 name mangling，此时真实属性名变成_MyClass__private_method，必须 patch 这个 mangling 后的名字
双下划线私有方法需处理 name mangling
当方法名以 __ 开头（如 __helper），Python 会在类作用域内自动重命名为 _ClassName__helper。mock 时若仍按原名 patch，会失败——因为实例上调用的其实是 mangling 后的名字。
例如：
class Processor:
def run(self):
return self.__do_work() # 实际调用的是 _Processor__do_work
<pre class="brush:php;toolbar:false;">def __do_work(self):
return "real"
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
要 mock 它，必须写：
@patch('mymodule.Processor._Processor__do_work')- 或者更稳妥地，在测试中先确认名字：
print(dir(Processor()))，找带_Processor__前缀的项 - 避免在类里滥用
__——除非真需要防止子类意外覆盖；单下划线_已足够表达“内部使用”意图，且无 mangling 麻烦
Mock 返回值与副作用必须匹配原始方法签名
私有方法常被设计为返回特定类型（如 dict、bool、自定义对象），或有参数（包括 self）。mock 时若返回类型不兼容，会导致被测方法抛出 AttributeError 或逻辑错误，但错误堆栈可能指向业务代码而非 mock 设置，排查困难。
- 用
return_value设定返回值时，确保类型和结构与原方法一致（比如原方法返回{'status': 'ok'}，就别 mock 成字符串） - 若私有方法有参数（如
_parse_input(self, data: str)），mock 不影响参数检查，但调用时仍会传入实参；若需验证参数，用assert_called_with(...) - 慎用
side_effect：如果原方法抛异常，mock 应模拟相同异常类型（如side_effect=ValueError），否则上层 try/except 可能不触发
更推荐：重构为可测试的设计，而非强依赖 Mock 私有方法
频繁需要 mock 私有方法，往往说明被测单元职责过重或边界不清。比如一个 process() 方法里混着网络请求、数据清洗、格式转换，其中清洗逻辑藏在 _clean_data() 里——这时更好的做法是把 _clean_data 提成独立函数或策略类，再单独测试。
- 把核心逻辑拆出类，作为模块级函数（如
def clean_data(raw: str) -> dict:），它天然可 import + mock - 若必须保留在类内，考虑将其设为
@staticmethod或@classmethod，这样 patch 路径更稳定（如patch('mymodule.MyClass.clean_data')） - 单元测试应聚焦“行为契约”：输入 → 输出 / 副作用，而不是“是否调用了某个私有方法”。过度断言私有实现细节会让测试脆弱
name mangling 和 patch 路径错位是最常卡住人的点，动手前先用 dir(instance) 确认真实属性名，比猜更可靠。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
