严格模式启用后，with语句、给只读属性赋值、删除不可配置属性、函数参数名重复、访问arguments.callee/caller均会直接报错。
严格模式启用后，哪些常见写法会直接报错？
JavaScript 严格模式（"use strict"）不是新语法，而是一组限制性语义规则。一旦启用，原本“静默失败”的错误行为会变成显式 TypeError 或 SyntaxError。
-
with语句被完全禁止，使用即抛SyntaxError - 给只读属性赋值（如
NaN = 1、undefined = 2）触发TypeError - 删除不可配置属性（如
delete Object.prototype）报TypeError - 函数参数名重复（
function foo(a, a) {}）在严格模式下是SyntaxError -
arguments.callee和arguments.caller被禁用，访问即TypeError
为什么 eval 和 arguments 在严格模式下变“干净”了？
非严格模式中，eval 可以在当前作用域动态声明变量或函数，导致静态分析失效；arguments 对象与形参自动绑定（修改 arguments[0] 会同步改 a），造成隐蔽副作用。
- 严格模式下，
eval总是在独立作用域执行，不影响外层变量 -
arguments不再与形参共享内存 —— 修改arguments[0]不影响参数变量a，反之亦然 - 函数内不能用
arguments作标识符（function f(arguments) {}是语法错误）
严格模式如何修复 this 的历史混乱？
非严格模式下，全局函数调用时 this 指向 window（浏览器）或 global（Node.js），容易引发意外的全局污染和 this 绑定丢失。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- 严格模式中，普通函数调用时
this为undefined，避免隐式绑定到全局对象 -
call/apply/bind传入null或undefined时，this就是null/undefined，不再自动转成全局对象 - 箭头函数不受此影响（它本就不绑定
this），但普通函数的行为更可预测
现在还需要手动加 "use strict" 吗？
现代 JavaScript 模块（.mjs 文件、import/export 的脚本）默认启用严格模式，无需显式声明。但传统 <script></script> 标签或 CommonJS 模块仍需手动开启。
- 模块脚本：所有顶层代码和函数体默认严格模式，包括异步函数、生成器函数
- 类（
class）内部所有方法自动运行在严格模式下 - 仍建议在非模块脚本顶部加
"use strict"，尤其当代码可能被拼接或压缩时 —— 压缩工具有时会破坏字符串字面量位置
"use strict";
function foo() {
// 这里是严格模式
console.log(this); // undefined，而非 window
}
真正容易被忽略的是：严格模式的边界由作用域决定，不是文件级开关。一个函数内用了 "use strict"，只影响该函数及其嵌套函数，不影响外部或同级其他函数。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
