python私有方法实为名称修饰而非真正私有，mock需用修饰后名如_myclass__helper，目标必须是模块可导入路径，不应测试私有方法而应聚焦公有接口。
私有方法在Python里根本不是“私有”的
Python没有真正的访问控制，_method 或 __method 只是约定或名称修饰（name mangling），不是屏障。想 mock 私有方法，本质是 mock 一个可访问的函数名——关键在于知道它被重命名成什么。
比如类 class MyClass: 中定义了 def __helper(self):，实际在实例上可通过 _MyClass__helper 访问。直接 patch 这个修饰后的名字才有效，patch __helper 会失败。
- 用
dir(instance)查看实际属性名，快速确认修饰结果 - 不要 patch
self.__helper—— 这在测试中不合法，self是运行时对象，不是模块路径 - 推荐 patch 路径形式：
my_module.MyClass._MyClass__helper，而不是实例方法绑定后的对象
mock.patch 的目标必须是“可导入路径”
mock 不是拦截调用栈，而是替换模块/类字典里的对象引用。所以 patch 目标必须写成从模块顶层可导入的形式，比如 myapp.services.UserService._UserService__validate_token，而不是 user_service.__validate_token。
常见错误是误以为 patch 实例方法就能生效——其实被 patch 的必须是类定义所在位置的原始函数，否则实例调用时仍走原逻辑。
图片提示词生成器？不止如此。 马甲系统 —— 把脑海中的画面，翻译成AI能理解的专业表达。 用得越多，它越懂你：首次需要多问几句确认方向，用久了几乎一说就懂。 用得越多，它越快：缓存机制让后续对话越来越省。 RAG进化：成功案例持续入库，越跑越聪明。 输入「新手指南」查看完整功能介绍
- 若私有方法在
utils.py的Helper类里，patch 目标是utils.Helper._Helper__parse_config - 用
@patch('my_module.MyClass._MyClass__do_work')比在 test 方法里patch.object(obj, '_MyClass__do_work')更可靠，后者只影响该实例，不覆盖类方法调用链 - 注意：如果私有方法被其他公有方法调用，且你 patch 的是实例上的绑定方法（
patch.object(instance, ...)），而公有方法内部是通过self.__xxx()调用的，那 patch 无效——因为self.__xxx在运行时仍解析为类上的修饰名
测试私有方法本身？通常没必要
私有方法是实现细节，单元测试应聚焦公有接口的行为。强行测试私有方法，往往意味着设计过深、职责不清，或把测试当成代码覆盖率游戏。
真遇到必须验证逻辑的情况（比如复杂算法封装在 __calculate_score 里），优先考虑：把它抽成独立函数，放到模块级，然后直接测试；或者用公有方法的输入输出反向验证。
- 如果坚持测私有方法，确保它不依赖其他私有状态（比如
self.__cache），否则 patch 成本飙升 - 避免在测试中大量使用
getattr(obj, '_MyClass__xxx')()—— 这会让测试和内部命名强耦合，重构时极易断裂 - pytest + pytest-mock 可以用
mocker.patch简化写法，但目标路径规则完全一致，别指望它绕过 name mangling
__getattr__ 和动态私有方法更麻烦
如果类重写了 __getattr__，或私有方法是运行时动态生成的（比如用 types.MethodType 绑定），那么名称修饰可能失效，patch 路径不再稳定。
这种情况下，mock 基本失效，得换思路：要么改写设计（避免动态私有行为），要么在公有方法入口打桩，用 side_effect 控制返回值，再断言最终效果。
- 检查是否真需要 mock —— 有时用真实依赖加
unittest.mock.Mock(spec=...)更稳妥 - 如果私有方法调用了外部服务，建议把该依赖抽成可注入参数，而不是死磕 patch 私有方法
- name mangling 在继承链中会变化，子类调用父类
__init后，父类私有方法名仍是_Parent__xxx，不是_Child__xxx—— 这点容易搞错
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
