Appearance
TypeScript 工程实践：strict、边界校验与类型债务控制
主题边界
- 工程实践关注的不是会不会写类型，而是类型系统如何与模块边界、构建链和运行时验证配合。
- 单文件里写出复杂类型，不等于项目获得了真实类型安全。
机制与流程
strict、noUncheckedIndexedAccess、exactOptionalPropertyTypes等配置决定编译器的保守程度。- API 输入、环境变量、URL 参数、本地存储和第三方 SDK 返回值都属于不可信边界，需要 schema 校验与类型推断协作。
- 项目中的类型债务常来源于
any泄漏、过度断言、重复类型定义和缺少边界建模。
关键差异
- “类型全”不等于“类型准”，最关键的是边界输入是否经过真实验证。
- 应用项目关注边界与维护成本，库项目更关注公开 API 表达力和兼容性。
边界条件
- 一开始就追求极致类型体操会抬高维护成本，不一定适合业务团队。
- 对历史项目强推严格配置通常需要分阶段迁移，否则会被大量存量错误淹没。
工程落点
- 推荐把类型策略落在目录边界、接口层、表单层和公共工具层，而不是平均撒在每个文件。
- 类型系统应该帮助定位真实 bug、提升重构安全性，而不是制造只会让人绕开的编译噪音。