纵深防御

问题：修好了，但结构上还会再犯

由「非法数据」引发的 bug，常规修法是在发现坏值的那行补一个校验。这套修法有个共同的失败模式：数据并不只从一条路径进来。另一个调用方、一次重构、一个 mock 对象，都可能绕过刚加上的那个 if。

结果就是同一个 bug 被反复发现，只是出现在不同的代码路径上。根因其实不是「少写了一个校验」，而是把防御当成了单点职责。

它怎么工作：四层校验加一次试绕过

技能扮演健壮性设计助手。输入是根因结论、数据流路径与涉及函数，输出一份结构化的 DefensePlan，包含四层校验清单、逐层测试标记与结果。

四层自下而上覆盖：

• 入口校验：在 API 或函数边界拒绝明显非法输入，例如目录参数为空或不存在即抛错。
• 业务逻辑校验：在本操作语境下确认数据「讲得通」，例如初始化工作区要求 projectDir 非空。
• 环境守卫：在特定上下文阻止危险操作，例如测试环境下拒绝在临时目录之外执行 git init。
• 调试埋点：其他层失效时保留取证能力，例如危险操作前记录目录、cwd、环境变量与堆栈。

落地按四步走：追溯数据流（坏值从哪来、在哪被消费）；列出数据经过的每一个检查点；每层补上校验；最后主动试绕过第 1 层，确认第 2 层能兜住。

关键认知是四层各自不可替代——不同代码路径会绕过入口，mock 会绕过业务逻辑，跨平台边界情况需要环境守卫，结构性误用要靠日志定位。

适用边界

• 适合在已修复由无效或边界数据引发的缺陷后做加固。
• 适合担心单点校验被其他路径、重构或 mock 绕过的场景。
• 适合需要在测试等特定环境阻断危险操作的场合。
• 不适合纯算法正确性（非数据合法性）问题；校验粒度应由使用方决定。
• 产出的 DefensePlan 可交给后续验证或代码评审环节继续消费。