JavaScript无法mock类私有方法（#method）是因ES规范限制其外部不可访问，非工具缺陷；可行方案包括重构为protected方法、依赖注入、测试公有行为契约，而非强行破解封装。
JavaScript 中无法直接对类的私有方法（#method）进行 mock，因为私有字段和方法在语言层面不可外部访问，Jest、Sinon 等主流测试工具均不支持拦截或替换它们。这不是工具限制，而是 ES 规范的设计约束——私有成员只在类定义内部可见。
为什么不能 mock 私有方法
私有方法不是对象属性，不挂载在实例上，也不出现在 Object.getOwnPropertyNames() 或 Reflect.ownKeys() 结果中。任何试图通过 jest.spyOn(instance, '#xxx') 或 jest.mock 拦截它的操作都会报错或静默失败。
真正可行的替代方案
-
重构为受保护方法（推荐）：把逻辑抽离成
protected或包级可访问的普通方法（如_doSomething()），再用jest.spyOn(instance, '_doSomething').mockImplementation(...)替换。这是最清晰、可测、符合测试友好的设计。 -
依赖注入 + 回调函数：将私有逻辑封装为独立函数，作为参数传入类构造器或方法。测试时直接传入 mock 函数，绕过类内部实现。例如：
new Service({ fetcher: jest.fn() })。 -
测试行为而非实现：聚焦公有方法的输入输出。只要
publicMethod()在给定输入下返回预期结果并触发了正确副作用（如调用了某 API、发出了事件），就无需关心它内部是否调用了哪个私有方法。 -
使用代理或装饰器暴露（仅限开发调试）：在非生产环境，可通过
Proxy包装实例，或在类中添加临时的__debugExpose方法返回私有逻辑的引用——但上线前必须移除，不可用于正式测试。
需要避开的误区
不要尝试用反射（Object.getOwnPropertyDescriptors）、eval、重写 Function.prototype.toString 等方式“破解”私有性。这些做法脆弱、不可靠，且破坏封装，会导致测试难以维护、容易随 JS 引擎更新而失效。
不复杂但容易忽略：mock 的目标从来不是“覆盖所有代码行”，而是验证模块在边界条件下的行为是否符合契约。把精力放在接口契约和可观测结果上，比强行 mock 私有细节更有效。
