javascript严格模式是什么_它能解决哪些潜在问题？_网络技术

严格模式强制变量声明、禁用隐式全局变量、使this在非对象调用时为undefined、禁止arguments.callee等不安全语法，并隔离eval和arguments作用域。

严格模式开启后变量必须声明才能使用

不加 "use strict" 时，给未声明的变量赋值会自动创建全局变量，容易污染全局作用域、掩盖拼写错误。开启后直接报 ReferenceError。

常见错误现象：name = "Alice" 在非函数作用域或普通函数中执行，没报错但悄悄挂到 window.name（浏览器）或 global.name（Node.js）上。

实操建议：

在脚本顶部或函数体第一行写 "use strict"（注意：必须是字符串字面量，且不能有前置语句）
避免在 with 块内启用严格模式（语法不允许）
模块（.mjs 或 import/ export 的文件）默认启用严格模式，无需手动加

禁止静默失败的赋值操作

严格模式让原本“看似成功”的非法操作立刻抛错，比如给不可写属性赋值、给只读全局对象（如 undefined、NaN、Infinity）重新赋值、删除不可配置属性等。

典型错误示例：delete Object.prototype 在非严格模式下返回 false 却不报错；严格模式下直接抛 TypeError。

实操建议：

检查旧代码中是否依赖 delete 返回布尔值做判断——严格模式下该行为不可靠
this 在非对象上下文（如普通函数调用）中不再绑定到全局对象，而是 undefined，避免意外修改全局状态
避免在构造函数外使用 new.target，它在严格/非严格下行为一致，但仅在严格模式下对箭头函数有效（实际箭头函数无 new.target）

限制存在安全隐患或易混淆的语法

严格模式禁用了一些歧义大、维护性差或已被废弃的特性，例如：

常见被禁用项：

arguments.callee 和 arguments.caller —— 无法再通过 arguments 反向获取函数本身，消除递归匿名函数的隐式依赖
八进制字面量（如 010）—— 改为必须写 0o10 或 0x10，避免数字开头零引发误解
函数参数名重复（function foo(a, a) { }）—— 严格模式下直接语法错误，非严格模式仅保留最后一个值
eval 和 arguments 不能作为标识符（var eval = 1 报错）

这些限制不是为了“多此一举”，而是让代码行为更可预测、更容易被静态分析工具识别问题。

严格模式对 `eval` 和 `arguments` 的隔离更彻底

非严格模式下，eval 内部声明的变量会泄漏到外层作用域；arguments 对象与形参保持“双向绑定”（改 arguments[0] 会同步影响 a）。

严格模式切断这两类隐式耦合：

eval("var x = 1"); console.log(x); → 报 ReferenceError（x 不泄露）

function foo(a) {
  "use strict";
  arguments[0] = 2;
  console.log(a); // 仍输出原值，如传入 1 则输出 1
}

这点在调试或重构带 eval 的老代码时特别关键——你不能再假设 eval 是“作用域黑洞”，它现在真正沙箱化了。

严格模式不是银弹，但它把很多“运行时不报错却逻辑错”的坑提前暴露出来。最容易被忽略的是：模块默认严格、IIFE 中漏写 "use strict" 导致子作用域仍处于宽松状态、以及第三方库未启用时带来的行为不一致。上线前用 ESLint 开启 strict 规则或检查打包产物是否保留了严格指令，比运行时靠运气发现更可靠。

# javascript # java # js # node.js # node # 浏览器 # 工具 # win # 作用域

相关栏目：【网站优化151355 】【网络推广146373 】【网络技术251813 】【 AI营销90571 】