类型系统不是保险箱：大型项目的类型收窄策略

类型能解决和不能解决的问题

静态类型擅长捕捉拼写错误、参数顺序错误、空值遗漏和结构不匹配，这类问题在动态语言里往往要到运行时才暴露。它不擅长表达业务约束，比如余额不能为负、状态只能沿特定路径流转，这些用类型表达的成本通常远高于用测试与断言表达。

认识到这条边界很重要。把业务规则硬塞进类型系统，最后往往得到一堆难懂的泛型嵌套，可读性下降而实际收益有限。

严格程度的推进方式

把严格模式一次性打开，在存量项目上通常会产生成千上万条报错，团队很快就会退回去。更可行的做法是分层推进：先让新代码遵守严格规则，老模块逐步迁移，用目录或者包为单位记录进度。

配套的度量是必要的。统计每个模块的违规数量并定期公示，能让迁移过程有可见的进展，也能避免某个模块长期被遗忘。

断言与校验的边界

来自外部的数据——接口响应、配置文件、用户输入——在进入系统时就应该做运行时校验。类型标注在这里只能算文档，因为编译期无法验证外部数据的真实形状。

把校验放在边界上，系统内部就可以信任数据形状，不必处处防御。这样既保留了类型带来的简洁，也避免了外部数据引发的问题渗透到深层逻辑。

泛型的成本控制

泛型是表达能力的来源，也是复杂度的来源。层数超过三层之后，类型报错信息往往变得难以理解，新人排查问题的时间会明显变长。

经验上的做法是给复杂类型起名字，拆成若干中间类型，并且在关键位置写明用途。宁可多写几行定义，也不要让调用方去猜一个嵌套结构到底想表达什么。

与测试的分工

类型检查适合覆盖结构层面的一致性，测试适合覆盖行为层面的正确性。两者重叠的部分不多，互相替代的效果都不好。用类型去做本该由测试完成的事，会得到一堆难以维护的类型技巧；反过来完全依赖测试去发现拼写与结构错误，则会浪费大量运行时。

比较均衡的配比是：类型负责接口契约，单元测试负责逻辑分支，端到端测试负责关键路径。三者各自的失败信号要清晰，才能快速定位问题所在。