TypeScript 运行时校验不要只靠类型

TypeScript 很容易给人一种安全感，好像只要类型定义得足够完整，系统就自然稳定了。但只要项目和接口、配置文件、第三方返回值发生交互，很多问题其实都发生在运行时，而不是编辑器里。

我自己踩过的坑里，最典型的就是“类型写得很好看，线上数据却完全不是那个样子”。接口字段缺失、环境变量格式不对、配置中心返回了一个意料之外的枚举值，这些情况 TypeScript 本身都挡不住，因为它并不会替你做实际值校验。

所以我现在更倾向把类型和运行时校验分开理解。类型负责表达我们期望的数据结构，运行时校验则负责在边界处确认真实数据是否符合预期。尤其是输入边界越多的系统，这个习惯越重要。

真正有价值的地方，在于你可以把错误挡在系统入口，而不是等到内部逻辑跑偏以后才发现类型和现实不一致。这样排查问题时，边界会清楚很多，错误信息也更容易给到调用方。

TypeScript 帮我们减少了一大类错误，但它从来不是运行时保险箱。编译期和运行时都守住，系统才会真正稳下来。

工具链问题真正影响的是团队节奏，而不只是命令能不能跑

像「TypeScript 运行时校验不要只靠类型」这样的工程化主题，很容易在早期被当成“开发者自己适应一下就好”。但只要它进入 monorepo、CI、镜像构建或多环境协作场景，问题就不再是单机体验，而是整个团队的交付节奏。一个看起来只是配置细节的决定，后面往往会变成缓存命中率、构建稳定性、版本兼容和排查效率的差异。

我会优先确认的工程约束

• 先验证这套工具在本地、CI 和生产镜像里是否拥有一致行为，别让“我电脑上能跑”变成默认前提。
• 把锁文件、缓存目录、类型入口和构建产物边界写清楚，避免升级一次就把下游一起拖进不确定状态。
• 如果某个新工具的收益主要停留在启动更快，而迁移和排错成本已经明显抬升，就说明采用边界需要收窄。