启用严格类型检查编译：让代码问题提前暴露

开发中遇到运行时莫名其妙的类型错误，比如把字符串当数字计算、对象属性访问报 undefined，这类问题在项目大了之后特别难查。很多人等到程序跑起来才发现问题，其实可以在编译阶段就堵住漏洞——启用严格类型检查编译就是关键。

为什么需要开启严格类型检查

以 TypeScript 为例，默认情况下，TS 对类型的宽容度比较高。比如你声明一个变量没写类型，它会自动推断为 any，等于放任不管。这时候看似省事，后期维护时容易踩坑。比如下面这段代码：

function calculateTax(income) {
    return income * 0.1;
}

calculateTax("5000"); // 字符串传进去了，结果是 NaN

如果不做任何限制，这段代码能通过编译，但运行时出错。而一旦启用严格类型检查，TS 就会直接报错：参数 income 缺少类型标注，且调用时传入了不兼容的类型。

如何启用严格模式

在 tsconfig.json 中加入以下配置即可开启严格类型检查：

{
  "compilerOptions": {
    "strict": true,
    "noImplicitAny": true,
    "strictNullChecks": true,
    "strictFunctionTypes": true
  }
}

其中 strict: true 是总开关，会激活一系列子规则。也可以单独开启某一项，按团队接受程度逐步推进。

实际排错场景：接口数据结构变动

某次上线后发现用户信息页面空白，排查发现后端返回的用户对象少了 avatar 字段。原本代码里直接使用 data.avatar 导致报错。如果之前启用了 strictNullChecks，TS 编译时就会提示“可能为 null 或 undefined”，逼你在使用前做判断：

if (user.avatar) {
    renderAvatar(user.avatar);
}

这种防御性编码习惯配合严格类型检查，能把很多线上问题拦在发布前。

别让“省事”变成“找事”

有些团队为了赶进度，选择关闭严格模式，觉得“先跑起来再说”。可随着代码量增长，类型混乱的问题像雪球一样越滚越大。新人接手看不懂变量来源，重构时不敢动老代码，调试时间远超前期配置成本。

就像装修房子，水电走线藏进墙里之前不验收，等贴完瓷砖再漏水，代价就大了。启用严格类型检查，本质是给代码加一层“施工规范”，让问题早暴露、早解决。

现在主流框架如 Vue 3、React + TS 模板都默认推荐开启 strict 模式。工具链支持已经很成熟，没必要再裸奔写代码。