TypeScript 中的 strict
说明 strict 为什么是 TypeScript 配置的总开关、它会开启什么类型检查族选项,以及为什么升级 TS 版本后 strict 项目更容易出现新报错。
#tech / dev
#resource / typescript
#type / concept
#status / growing
[!info] related notes
- 所属 MOC: TypeScript MOC
- 配置入口: tsconfig 使用详解
- 并列概念: TypeScript 类型检查, TypeScript 中的 target, TypeScript 中的 noImplicitAny, TypeScript 中的 noImplicitThis, TypeScript 中的 strictNullChecks, TypeScript 中的 strictFunctionTypes, TypeScript 中的 strictBindCallApply, TypeScript 中的 strictBuiltinIteratorReturn, TypeScript 中的 alwaysStrict, TypeScript 中的 strictPropertyInitialization, TypeScript 中的 noUncheckedIndexedAccess, TypeScript 中的 exactOptionalPropertyTypes, TypeScript 中的 useUnknownInCatchVariables
TypeScript 中的 strict
一句话定义
strict 是 TypeScript 一组严格类型检查行为的总开关。
核心机制 / 工作原理
当配置:
{
"compilerOptions": {
"strict": true
}
}
时,TypeScript 会同时开启一组 strict family 选项。
官方文档明确说明:
strict等价于打开一整组更严格的类型检查行为- 之后仍然可以按需单独关闭某个子开关
最小例子 / 最小场景
常见默认推荐
{
"compilerOptions": {
"strict": true
}
}
这通常是现代 TypeScript 项目的推荐起点。
为什么它重要
strict 的价值不在于“更难写代码”,而在于更早暴露:
- 空值风险
- 隐式
any - 过宽的函数参数 / 返回值
- 类型收窄不完整
当前更值得单独拆出来理解的 strict family 子项包括:
- TypeScript 中的 noImplicitAny
- TypeScript 中的 noImplicitThis
- TypeScript 中的 strictNullChecks
- TypeScript 中的 strictFunctionTypes
- TypeScript 中的 strictBindCallApply
- TypeScript 中的 strictBuiltinIteratorReturn
- TypeScript 中的 alwaysStrict
- TypeScript 中的 strictPropertyInitialization
边界与易混淆点
strict 不是单一规则
它是一个总开关,不是一条具体报错规则。
开了 strict 不代表类型系统就完整了
它能显著提高静态保证,但仍然不能替代:
- 运行时校验
- 外部输入验证
- API schema 校验
升级 TypeScript 时可能出现新报错
官方文档特别提醒:未来 TypeScript 版本可能会把新的更严格检查纳入 strict,所以升级后项目可能新增类型错误。
很多团队还会额外叠加更细的安全开关
例如索引签名访问的安全性,就常继续细化到:
可选属性和 catch 变量的语义,也常继续细化到:
另外还有一些常和 strict 搭配使用、但更像相邻质量开关的选项,例如:
- TypeScript 中的 noImplicitReturns
- TypeScript 中的 noFallthroughCasesInSwitch
- TypeScript 中的 noUnusedLocals
- TypeScript 中的 noUnusedParameters
参考信息
- TSConfig
strict: https://www.typescriptlang.org/tsconfig/strict.html