测试私有函数应优先通过公有接口间接验证，其次可条件暴露或抽离为纯函数单独测试，避免强行破解闭包。
JavaScript 中没有真正的私有函数，所谓“私有”只是靠作用域或约定实现的封装。因此，测试私有函数的内部逻辑，关键不在于“绕过访问限制”，而在于**设计可测性**和**选择合适策略**。
优先通过公有接口间接验证私有逻辑
这是最推荐的做法。私有函数本就不该被直接调用，它的行为应完全由对外暴露的 API 驱动和约束。
- 把私有函数看作实现细节，测试重点是“输入 → 输出”是否符合预期
- 构造边界、异常、典型等多组输入，断言公有方法的返回值、副作用（如状态变更、事件触发、DOM 变化）
- 例如：一个
calculateTotal()公有方法内部调用了私有的_applyDiscount()和_addTax()，你只需验证不同折扣率和税率下calculateTotal()的最终结果是否正确
在模块/类内部暴露私有函数用于测试（仅限开发环境）
如果确实需要单独验证某段复杂逻辑（比如算法、数据转换），可在模块导出或类实例上条件性暴露私有函数，但必须确保它不会进入生产代码。
- 使用
process.env.NODE_ENV === 'test'或类似机制控制是否挂载 - ES 模块示例：
function _parseDate(str) { /* ... */ }<br>function formatDate(date) { return _parseDate(date).toISOString(); }<br><br>// 仅测试时暴露<br>if (typeof window !== 'undefined' && window.__TEST__) {<br> window.__TEST__._parseDate = _parseDate;<br>}<br>export { formatDate }; - 在 Jest 测试中临时启用：
global.__TEST__ = {};，然后调用global.__TEST__._parseDate(...)
重构为独立、无副作用的纯函数并单独测试
将难以测试的私有逻辑抽离成独立模块或顶层函数，既提升复用性，也天然支持单元测试。
立即学习“Java免费学习笔记（深入）”；
- 例如把类中复杂的校验逻辑
_validateInput()提取为src/utils/validator.js中的导出函数 - 该函数不依赖 this、不读写外部状态、只依赖参数，可直接
import { validateInput } from './validator';并测试 - 原类中只需调用这个已验证过的函数，降低主模块测试复杂度
避免强行测试无法访问的闭包内函数
不要尝试用 eval、Function 构造器、AST 解析或重写源码等方式“破解”闭包——这会让测试脆弱、难维护，且违背封装意图。
- 这类做法会耦合实现细节，一旦函数重命名或移动位置，测试立刻失败
- 测试变相成了“检查代码怎么写的”，而不是“检查功能对不对”
- 真正的问题往往出在设计：函数职责过重、逻辑未解耦、缺乏抽象层
