类型检查不是保险箱：大型项目里的收窄策略

引入静态类型之后，团队常有一种安全感：错误应该在编译阶段被挡住。实践中却发现，大型项目里真正引发线上问题的错误，多数依然发生在数据边界——配置读取、接口响应、文件解析与外部输入。这些位置一旦用了宽松的类型表述，检查能力立刻失效。

有效的做法是把校验集中在边界，往里传递时保持严格。入口只做一次外部数据到内部结构的转换，转换失败当场报错并给出可读提示。之后所有模块面对的都是已确认的内部结构，不必在每个函数里重复判断，也不会出现层层宽松表述把问题推到深处。

反过来，如果每个模块各自做判断，问题会更麻烦：判断依据分散，规则冲突难以发现，同一份数据在不同路径上的可信度不一致。很多老项目的重构成本正来自这里，把散落的判断收回到边界层，是收益相对确定的一步。

类型表述要区分可选与允许空值。前者是字段可以不提供，后者是字段一定要提供但值可能为空，两者含义不同。混用会让调用方猜，猜错的代价是运行时异常。在接口文档中把这两类分开写清楚，比加一层防御式判断更有效。

最后一项判断标准是改造顺序。不要指望一次性把整个项目收紧，那会造成长期无法发布的重构。现实可行的路径是先给新增代码定规则，再挑调用最频繁的核心模块逐个收紧，每步都能独立验证。类型检查的价值不在于覆盖率数字，而在于边界处的那几次正确报错。