用途：当错误发生在执行深处而非入口点、堆栈显示很长的调用链、无法判断无效数据从何而来，或需要找出是哪个测试或代码触发问题时使用。
主要思路：不要让修复停在报错位置，而是沿调用链逐层向上回溯，找到最初的触发点，在源头修复，并在各层补充校验作为纵深防御。
追踪过程：先观察症状，再定位直接原因（哪段代码直接导致该错误），然后逐层追问“是谁调用了它”，继续向上追溯传入的值，最终找到原始触发点。例如 cwd 被传成空字符串会解析为 process.cwd()，从而在源码目录执行 git init。
当无法手工追踪时，可在危险操作前加入埋点：使用 new Error().stack 捕获完整调用链，用 console.error() 输出目录、cwd、环境变量和堆栈；在测试中用 console.error() 而非 logger，因为 logger 可能被抑制。运行 npm test 2>&1 | grep 'DEBUG git init' 可捕获输出，再从堆栈中查找测试文件名、触发行号和重复模式。
修复后验证：可依据复杂度决定是否编写确定性单元测试，覆盖复杂算法、业务逻辑、易出错的数据转换和可能静默失败的关键路径；UI 组件、React hook、简单 CRUD 和直接映射可跳过测试，改用类型检查、lint、手动验证或代码审查确认。只做确定性单元测试，不写集成测试，不做复杂 mock 和异步复杂度。
限制：以上为公开资料描述的方法与流程，未提供具体安装命令、价格、平台或效果数据。