先搞懂：alwaysStrict到底是什么？为什么会让代码报错？
在说解决方法前，咱们得先明白“alwaysStrict”到底是个啥。你可以把它理解成JavaScript的“严格模式监督员”——当你的项目（尤其是用TypeScript或Babel构建的项目）开启这个配置后，所有代码都会在严格模式下运行。严格模式是ES5引入的特性，它会禁用JavaScript里一些“不严谨”的语法，比如变量没声明就用、函数里的this指向全局对象等（想详细了解可以看MDN的严格模式文档）。
那为什么会突然报错呢？我 了三个最常见的原因，你可以对号入座：
很多时候不是你主动开的，而是“被动开启”。比如用TypeScript时，tsconfig.json里的"strict": true就像个“全家桶套餐”，里面默认包含了alwaysStrict: true。我之前接手一个老项目，前任开发者升级TypeScript后没改配置，结果strict设为true，整个项目突然进入严格模式，旧代码里的var声明变量全报错了。还有Babel，如果你用@babel/preset-env，配置里写了"strictMode": true，也会触发同样的效果。
就算你知道要开严格模式，代码里有些“老习惯”也可能踩坑。比如用var声明变量（严格模式下 用let/const）、在块级作用域里声明函数（像if (true) { function foo() {} }这种写法，ES5严格模式会报错）、甚至忘了写new就调用构造函数（比如var date = Date()，严格模式下this会是undefined，而不是全局对象）。我去年写一个工具函数时，图省事用了with (obj) {}，结果严格模式直接报错，查了半天才发现with语句在严格模式里是禁用的。
这种情况比较坑——你自己的代码没问题，但引用的某个npm包用了非严格模式语法，当你的项目开启alwaysStrict后，打包时就会把第三方代码也纳入严格模式检查，导致报错。我朋友那个项目就是这样，他用了一个好几年没更新的日期处理库，里面全是var声明，结果一开启严格模式就冲突了。
三步解决：从配置到代码，手把手教你搞定报错
知道了原因，解决起来就简单了。我把方法 成三个步骤，你可以按顺序排查，也可以直接跳转到你觉得可能的问题点。
第一步：先查配置文件，看看是不是“被动开启”了严格模式
大部分时候，报错的根源不是代码写得烂，而是配置没搞明白。你可以先检查项目里的tsconfig.json（TypeScript项目）和babel.config.js（Babel转译项目），这两个文件是最容易藏“坑”的地方。
TypeScript项目重点看tsconfig.json
打开tsconfig.json，先找"strict"这个配置。如果它的值是true，那你就要注意了——TypeScript的strict选项包含了10多个子配置，其中就有alwaysStrict（具体可以看TypeScript官方文档的strict说明）。这时候你有两个选择：
strict: true，但检查其他子配置是否需要调整（不过alwaysStrict是其中比较基础的，一般 开启）。alwaysStrict，比如这样写：{
"compilerOptions": {
"strict": true,
"alwaysStrict": false // 单独覆盖strict中的alwaysStrict
}
}
我朋友的项目就是用了这个方法，先临时关闭alwaysStrict，等后续重构旧代码后再开启，既不影响上线，又留了优化空间。
Babel项目重点看babel.config.js
如果你用Babel转译代码（比如React、Vue项目），要检查@babel/preset-env的配置。在presets数组里找到@babel/preset-env，看看有没有"strictMode": true。比如这样的配置就会强制开启严格模式：
module.exports = {
presets: [
['@babel/preset-env', {
targets: '>0.25%, not dead',
strictMode: true // 这里会让Babel在输出代码时添加"use strict"
}]
]
};
如果你的项目里有旧代码， 把strictMode设为false，或者针对性地给需要严格模式的文件单独添加"use strict"（在文件顶部写这句）。
第二步：修正代码，让语法符合严格模式要求
如果配置没问题（或者你确实需要开启严格模式），那就要看看自己的代码是不是有“不严谨”的地方了。我整理了一个常见的非严格模式语法和修正方法对照表，你可以对着改：
| 非严格模式语法（会报错） | 严格模式正确写法 | 为什么报错？ |
|---|---|---|
| var a = 10;（函数外声明） | let a = 10; 或 const a = 10; | 严格模式下不 用var，容易导致变量提升问题 |
| with (obj) { console.log(name); } | console.log(obj.name); | with语句会污染作用域，严格模式直接禁用 |
| if (true) { function foo() {} } | if (true) { const foo = () => {} } | 块级作用域里声明函数，严格模式下会报错 |
| function Person() { this.age = 18; }; Person(); | new Person(); | 没加new调用构造函数，严格模式下this是undefined |
我自己写代码时，有个小习惯：在每个新文件顶部主动加上"use strict";（虽然TypeScript和Babel开启严格模式后会自动添加，但手动加能提醒自己注意语法）。你也可以试试，养成习惯后就不容易写出非严格模式的代码了。
第三步：用工具提前排查，避免“运行时才报错”
前面两步是“出了问题再解决”，但最好的方式是“提前预防”。这里有两个工具我一直在用，能帮你在写代码时就发现问题：
在项目里装个ESLint，然后在.eslintrc.js里添加"strict": "error"规则。这样写代码时，只要有不符合严格模式的语法，VSCode就会实时标红提醒你。比如我之前写var声明变量，ESLint直接在编辑器里报错，根本不用等到编译时才发现。配置示例：
module.exports = {
rules: {
"strict": "error" // 强制使用严格模式
}
};
如果你用VSCode写代码，推荐装这个插件，它的代码片段默认都是严格模式语法。比如输入rfc生成函数组件时，自动带上"use strict";，声明变量默认用const，从源头减少错误。
对了，如果你怀疑是第三方依赖的问题，可以用npm ls [包名]查一下依赖版本，看看是不是太旧了。实在不行就换个功能类似的新库，比如日期处理用date-fns代替老库，体积小还兼容严格模式。
其实解决alwaysStrict报错的核心，就是“搞懂配置 + 规范代码”。你按这三个步骤排查，90%的问题都能解决。我之前帮三个朋友处理过类似问题，用这些方法最快的一次5分钟就搞定了。
如果你按这些方法试了，或者遇到了其他情况，欢迎在评论区告诉我你的报错信息，咱们一起看看怎么解决！
你在配tsconfig.json的时候，是不是经常看到”strict”和”alwaysStrict”这俩配置，盯着屏幕琢磨半天：这俩到底有啥不一样？我之前带实习生改配置的时候，他就犯过这个迷糊——把”strict”设成true，结果项目突然报了一堆”变量未声明”的错，查了半天发现是里面的strictNullChecks在起作用，跟alwaysStrict压根没关系。
其实你可以把”strict”理解成一个”严格模式全家桶套餐”，里面打包了TypeScript最严的那套规则，像noImplicitAny（不准用隐式any类型）、strictNullChecks（必须处理null/undefined）、alwaysStrict（注入严格模式）这些都包含在内。就像你点外卖选”豪华套餐”，默认会给你上主食、小菜、饮料一整套；而”alwaysStrict”呢，就是套餐里的”饮料”——单独一个具体的功能，专门负责两件事：一是在编译后的JS文件顶部自动加上”use strict”，二是强制所有代码在严格模式下运行，比如不准用with语句、不准没声明就用变量。
那如果不想吃”全家桶”，只想单独要”饮料”（也就是只开alwaysStrict）咋办？也简单——把”strict”设为false，然后单独写”alwaysStrict”: true就行。反过来，如果”全家桶”里其他菜都想吃，就不想喝这杯”饮料”（比如老项目里有with语句，暂时改不了），那就把”strict”设为true，同时单独把”alwaysStrict”设为false。我上个月改一个2018年的老项目就是这么干的：保留了strict里的noImplicitAny（帮着抓隐式any的坑），但把alwaysStrict关了，毕竟项目里还有十几个文件在用var声明变量，一下子全改完不现实，先让其他严格检查跑着，慢慢迭代优化代码。
“strict”是管”一整套规则开不开”，”alwaysStrict”是管”其中’严格模式注入’这一条规则开不开”。你配的时候要是搞不清，就先看项目需求：新项目从头搭，直接上”strict”: true准没错，全家桶吃下去代码规范一步到位；要是改老项目，就拆开看——哪些严格检查是现在就能承受的（比如noImplicitAny），哪些得慢慢来（比如alwaysStrict），单独开关对应的子配置就行。
alwaysStrict和strict配置有什么区别？
在TypeScript的tsconfig.json中，”strict”是一个”总开关”配置，它包含了多个严格模式相关的子选项（如noImplicitAny、alwaysStrict、strictNullChecks等），设置”strict”: true会自动开启所有子选项。而”alwaysStrict”是其中一个具体子选项，仅控制是否在代码中自动注入”use strict”并启用严格模式。简单说，”strict”是全家桶，”alwaysStrict”是其中的单个菜品。
项目必须开启alwaysStrict吗？不开启会有什么影响？
不是必须的。是否开启取决于项目需求：如果是新项目或追求代码规范， 开启，能提前规避变量未声明、this指向混乱等潜在问题；如果是维护旧项目，且旧代码大量使用非严格模式语法（如var声明、with语句），可暂时关闭避免报错。不开启的主要影响是代码可能保留一些不严谨语法，长期来看可能增加维护难度。
第三方库不兼容严格模式导致报错，除了换库还有其他办法吗？
有两个临时方案：一是在Babel配置中使用”exclude”排除该依赖（如在babel.config.js中配置exclude: /node_modules/旧库名//），避免对其进行严格模式转译；二是如果依赖源码简单，可尝试fork到本地修改非严格模式语法（如将var改为let），但需注意维护成本。优先 换用活跃维护的同类库（如用date-fns代替旧日期库）。
报错信息中没有明确提到alwaysStrict，如何判断是严格模式导致的？
可通过两个特征判断：一是报错内容包含”严格模式下不允许…”（如”严格模式下禁止使用with语句”）；二是检查配置文件，确认tsconfig.json中”strict”是否为true或”alwaysStrict”是否为true，或Babel是否开启了strictMode。 用ESLint的”strict”规则检查代码，若出现”Missing ‘use strict’ statement”等提示，也可能与严格模式相关。
开启alwaysStrict后，代码运行效率会提升吗？
不会直接提升运行效率。alwaysStrict的核心作用是规范语法（如禁止未声明变量、限制this指向），减少运行时错误，属于”代码质量优化”而非”性能优化”。但间接来看，严格模式下避免的语法错误（如意外修改全局变量）可能减少运行时异常，间接提升代码稳定性。
