严格模式通过”use strict”字符串字面量启用，须置于脚本顶部或函数体首行；模块默认启用。它禁用易错行为，如给只读属性赋值、删除不可配置属性、八进制字面量、参数重名、with语句等，并使全局函数中this为undefined而非window。
严格模式启用方式：只有一行代码，但位置很关键
javaScript 严格模式不是开关式配置，而是通过字面量字符串 "use strict" 激活。它必须出现在脚本顶部或函数体第一行，否则无效。
- 全局启用：整个 js 文件最开头写
"use strict";（注意是字符串字面量，不是语句） - 函数级启用：在函数体第一行写
"use strict";，只对该函数生效 - 不能写在条件块里，比如
if (true) { "use strict"; }—— 这完全不触发严格模式 - 模块（
.mjs或import加载的脚本）默认就是严格模式，无需手动加
严格模式下会报错的典型操作
严格模式不是“更严的语法检查”，而是禁用了一大批容易出错、歧义大或已被废弃的行为。以下操作在非严格模式中可能静默失败或产生意外结果，但在严格模式中直接抛 TypeError 或 SyntaxError：
- 给只读属性赋值：比如
NaN = 1、undefined = 2、Object.defineProperty(obj, 'x', { writable: false }); obj.x = 3 - 删除不可配置属性：
delete Object.prototype或delete obj.nonConfigurableProp - 使用八进制字面量：
010（严格模式下是语法错误；应改用0o10） - 函数参数重名：
function f(a, a) { }→SyntaxError - 使用
with语句 →SyntaxError -
eval和arguments不能作为变量名或形参名：function f(eval) { }或var arguments = [];
严格模式对 this 的影响：全局调用不再绑定到 window
这是最容易引发兼容性问题的一点。非严格模式下，顶层函数中未绑定的 this 默认指向全局对象（浏览器中是 window）；严格模式下，它就是 undefined。
- 常见踩坑场景：
function foo() { console.log(this); } foo();—— 非严格输出window，严格输出undefined - 事件监听器、定时器回调、第三方库内部调用函数时若依赖
this指向全局，升级严格模式后可能突然失效 - 解决方法不是绕开严格模式，而是显式绑定：
foo.call(window)、foo.bind(this)，或用箭头函数（但注意箭头函数不绑定this） - 模块默认严格，所以现代打包工具（如 webpack/vite）构建的代码基本都受此约束，需提前验证逻辑
如何排查严格模式相关报错
浏览器控制台报错不会直接说“这是严格模式导致的”，但错误类型和上下文能帮你定位：
立即学习“Java免费学习笔记（深入）”；
- 看到
Cannot assign to read only property、Invalid left-hand side in assignment、Delete of an unconfigurable property，基本可判定是严格模式拦截 - 检查报错代码所在作用域是否被
"use strict"覆盖（注意：函数内启用不影响外层，外层启用也不影响eval内部，除非eval自己声明） - 用
console.log(this === undefined)快速验证当前执行环境是否为严格模式（仅限函数内，且无显式绑定） - 不要在已有大型代码库中全局加
"use strict"后直接上线——先用 ESLint 规则strict+no-unused-vars等配合扫描潜在问题
严格模式本身没有运行时开销，但它放大了隐性错误。真正难处理的不是语法报错，而是那些原本“凑合能跑”的逻辑（比如依赖 this 指向 window 的老代码）在启用后突然中断——这类问题往往藏得深，得靠调用链回溯和作用域分析才能揪出来。