JavaScript 里的“紧箍咒”：为什么老手都爱写 use strict？

你有没有经历过这种抓狂时刻：深夜加班调试代码，明明逻辑没问题，页面却莫名其妙多出来一堆奇怪的数据，或者某个回调函数里的 this 指向突然变成了 window。当你翻来覆去检查语法时，发现罪魁祸首竟然是一个没声明的变量 foo，它悄无声息地成为了全局属性。

在传统的 JavaScript 宽松模式（Sloppy Mode）下，这种错误往往被编译器默默放过，留给运行时的隐患却是巨大的。这就像开车不系安全带，平时感觉挺爽，真出了事故才发现后果难扛。而 use strict，就是那个强制你系好安全带的开关。

开启严格模式只需要在文件顶部或函数内部写上 "use strict" 这一行字。别小看这短短几个字符，它实际上是给 JavaScript 引擎下达了一道指令：从现在开始，按更严格的规则执行代码。

很多人觉得现代框架已经自动处理了这些问题，没必要手动加这句。但现实是，很多遗留项目、工具脚本或者是跨环境运行的代码，依然暴露在宽松的陷阱里。了解它的核心价值，比单纯记住语法更重要。

最痛的点在于变量作用域。在普通模式下，如果你忘记用 var、let 或 const 声明变量，直接赋值 count = 10，浏览器会立刻在全局对象上创建一个名为 count 的属性。这极易造成命名污染，甚至覆盖掉其他模块的同名变量。但在严格模式下，这种行为会被直接拦截，抛出一个 ReferenceError。这意味着你的错误会在开发阶段就被暴露，而不是等到生产环境才爆发。

除了变量，另一个隐蔽的坑是 this 的指向。在非严格模式的普通函数中，如果未显式绑定上下文，this 默认指向全局对象 window。这对于编写模块化组件是个灾难，因为你可能本想操作局部数据，结果却改写了浏览器全局状态。严格模式下，未绑定的函数调用中，this 将为 undefined。虽然这看似让代码少了一些“容错”，但它迫使你明确依赖关系，写出逻辑更清晰的代码。

此外，还有一些容易被忽视的限制。比如，你不能在同一个函数内定义两个同名的参数，这在旧版本中是允许的，但很容易导致计算逻辑混乱。严格模式还禁止使用八进制字面量（如 010），防止数字解析歧义。甚至连删除不可配置的对象属性也会报错，而不是像以前那样静默失败。

当然，关于严格模式有一个常见的误区：是不是每段代码都必须加？答案是肯定的，尤其是当你编写独立的功能模块或公共库时。虽然 ES6 模块（ES Modules）默认就是严格模式，但如果你还在维护 CommonJS 规范的老项目，或者编写直接在 <script> 标签里运行的脚本，显式声明依然不可或缺。

在实际工程中，我倾向于将整个项目的顶层脚本都设为严格模式。如果你正在构建一个库，确保你的每个导出函数内部都能独立维持严格模式的状态。不要依赖环境的隐式设置，显式声明永远比隐式约定更安全。

有人担心加了之后会破坏兼容性。实际上，只要你的代码没有刻意利用那些“不合法的宽容特性”，比如访问非存在的属性作为 getter，严格模式通常是向下兼容的。它不会改变正常逻辑的运行结果，只是把那些游走在边缘的坏味道过滤掉了。

写完代码后，试着回头看看那些随意的赋值和模糊的 this 引用，你会发现加上 use strict 不仅是一种规范，更是一种对代码负责的态度。它像是在告诉未来的维护者：这里没有模糊地带，每一行都有据可依。

技术迭代的路上，新工具层出不穷，但基础语言的规范依然是地基。与其花时间修补那些因疏忽而产生的诡异 Bug，不如从一开始就用严格模式筑起防线。毕竟，好的代码不仅是能跑通，更要经得起推敲。