严格模式从底层约束对象创建、this绑定、继承和属性操作，强化原型链不可篡改性、规范构造函数调用、提升封装/继承/多态可靠性，并提高调试与测试准确性。
严格模式对原型链和面向对象编程的影响，不是简单“加个报错”这么表面，而是从底层约束了对象创建、this绑定、继承行为和属性操作的逻辑一致性。它让 JS 的 OOP 更接近设计本意，也暴露了非严格模式下被掩盖的隐性风险。
严格模式强化了原型链的“不可篡改性”边界
在非严格模式中，对不可配置属性（如 Object.prototype 上的 toString）执行 delete 或重新赋值，会静默失败；而严格模式下直接抛出 TypeError。这意味着：
- 原型链上关键内置方法（如 hasOwnProperty、isPrototypeOf）一旦被意外覆盖或删除，严格模式立刻中断执行，避免后续成员查找机制失效
- 使用 Object.defineProperty 修改原型属性时，若尝试将
configurable: false的属性设为writable: true，严格模式报错，而非忽略——这保障了原型对象状态的可预测性 - 对 __proto__ 的赋值（如
obj.__proto__ = {}）在严格模式中虽不禁止，但若目标不是对象或 null，会明确报错，防止原型链意外断裂
构造函数与 new 的行为被强制规范化
严格模式让构造函数真正“只该被 new 调用”，切断了 this 指向全局对象的歧义路径：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 普通函数内部若未用 new 调用，在非严格模式下
this指向window（或 global），容易造成全局污染；严格模式中this为 undefined，任何对this.xxx = y的赋值立即报错 - 这倒逼开发者必须显式使用 new，从而确保 [[Prototype]] 正确指向构造函数的
prototype，原型链继承关系不再依赖调用习惯 - 结合 new.target（ES6，但与严格模式协同更强），可进一步防御误调用：在严格模式构造函数中检查
!new.target并 throw，彻底杜绝非实例化调用
面向对象特性（封装/继承/多态）的实现更可靠
严格模式通过限制语言“松散行为”，让 OOP 的三大特性落地更扎实：
立即学习“Java免费学习笔记（深入）”；
- 封装：禁止在函数内随意使用 arguments.callee 或 caller，切断了对调用栈的隐式访问，促使开发者用命名函数或闭包显式控制作用域，私有逻辑更可控
-
继承：严格模式下，子类构造函数中若忘记调用 super()（ES6 class），会直接报错；即使手写寄生组合式继承，
this在未正确绑定前就访问父类方法也会失败，避免“继承了却没生效”的静默陷阱 -
多态：由于形参与 arguments 解耦（严格模式中修改 arguments 不再影响形参），方法重载模拟、参数校验等逻辑更稳定；同时禁止重复参数名（
function foo(a, a) {}），消除因参数映射混乱导致的多态行为偏差
对原型链调试和工具链提出更高要求
严格模式本身不改变原型链结构，但它的报错机制让开发过程更“诚实”：
- Chrome DevTools 中查看对象时，若原型链某环节抛错（如访问已 delete 的不可配置属性），会清晰显示错误位置，而不是返回 undefined 后继续执行——这对排查继承链断裂、方法丢失等问题非常关键
- 代码混淆或压缩工具需注意：严格模式下 eval 无法访问外层作用域变量，若原型方法里含动态 eval，可能破坏封装逻辑；建议将共享方法统一挂载到 prototype，避免运行时拼接
- 单元测试中，严格模式让“看似能跑通但实际逻辑错位”的 case 更容易暴露，比如测试子类方法是否真的复用了父类原型方法，而非意外创建了同名自有属性
