用途：当错误出现在执行链深层而非入口处、堆栈跟踪显示很长的调用链、无法判断无效数据来自哪里，或需要定位是哪个测试/代码触发问题时，使用 trace 沿调用链反向追踪，找到最初的触发点，再从源头修复。
主要能力：提供一套系统化追踪流程。先观察症状，找到直接原因，再逐层向上追问“是谁调用了它”，持续向上追踪传入的值与来源，直到找到原始触发器。若无法手动追踪，可添加临时插桩：在危险操作之前用 console.error() 输出目录、cwd、环境变量与 new Error().stack，再运行并捕获输出（资料示例为 npm test 2>&1 | grep 'DEBUG git init'），通过堆栈中的测试文件名与行号定位触发模式。修复后可按复杂度决定验证方式：复杂算法、业务逻辑、易错数据转换与关键路径写确定性单元测试；UI 组件、React hooks、简单 CRUD 与直接映射可跳过测试，改用 typecheck/lint、手动验证或代码审查。资料强调只写确定性单元测试，不做集成测试、复杂 mock 或异步复杂度。
使用方式：在测试中用 console.error() 而不是 logger（logger 可能被抑制）；在危险操作之前而非失败之后记录日志；日志包含目录、cwd、环境变量与时间戳；用 new Error().stack 捕获完整调用链。
适用场景与限制：适用于调试调用栈深、数据来源不明的缺陷。核心原则是绝不只修错误出现的位置，要追溯到原始触发点，并可在各层添加校验（如参数校验、空值校验、环境守卫、栈日志）形成纵深防御。资料未提供安装命令、平台支持、收费与价格信息。