严格模式通过强化this语义和错误反馈机制，使访问器中this失效时立即报错而非静默处理，倒逼开发者正确使用this；其默认指向被访问对象，但对undefined或非法this值抛TypeError，同时禁止隐式全局赋值等行为。
在严格模式下，访问器属性（getter/setter）中滥用 this 不是靠“额外禁止”，而是严格模式本身强化了 this 的语义和错误反馈机制——它让原本静默失败或意外绑定的行为立刻暴露为运行时错误，从而倒逼开发者正确使用 this。
访问器中 this 的默认行为在严格模式下更清晰
在 getter 或 setter 中，this 默认指向当前被访问的对象（即属性所在的对象），这点在非严格和严格模式下一致。但关键区别在于：一旦 this 实际为 undefined 或不合法值，严格模式会立即报错，而非静默忽略或绑定到全局对象。
- 非严格模式下：
const obj = { get x() { return this.y; } }; obj.x;若this意外丢失（如被间接调用），this.y可能返回undefined或读取window.y，不易察觉 - 严格模式下：同样代码若
this为undefined（例如通过Object.getOwnPropertyDescriptor(obj, 'x').get.call(undefined)调用），会直接抛出TypeError: Cannot read property 'y' of undefined
避免 this 失效的常见场景与写法
访问器中 this 失效通常不是语法错误，而是调用方式不当导致上下文丢失。严格模式不会阻止你写错，但会让错误更快浮现：
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 不要把 getter 当普通函数提取调用：
const getX = obj.x; getX();→ 严格模式下this为undefined，访问this.y直接报错 - 避免在箭头函数中定义访问器（箭头函数没有自己的
this，且访问器必须是普通函数）：get x() { return () => this.y; }是合法的，但内部箭头函数的this仍继承自 getter 执行时的this；真正要避免的是用箭头函数替代 getter 本身 - 构造函数中定义访问器时，确保实例化后访问：
class C { constructor() { Object.defineProperty(this, 'val', { get() { return this._data; } }); } }—— 若this._data未初始化，严格模式下读取会明确报错，而非返回undefined
主动防御：显式校验 this 的有效性
在关键访问器中，可手动检查 this 是否符合预期，提升健壮性：
立即学习“Java免费学习笔记（深入）”；
- 判断是否为预期构造函数的实例：
get value() { if (!(this instanceof MyClass)) throw new TypeError('value getter called on wrong context'); return this._val; } - 检查必要属性是否存在：
set name(v) { if (this === undefined) throw new Error('this is undefined'); this._name = String(v); } - 利用
Object.isExtensible或hasOwnProperty等辅助判断上下文完整性，而非依赖隐式行为
注意：严格模式不改变访问器语法限制
严格模式本身不新增对访问器的语法禁令（比如不允许 get 里用 this），但它让以下行为失效或报错：
- 在 getter 中给
this添加新属性（如果对象不可扩展）→ 报TypeError - setter 中尝试修改只读属性 → 报
TypeError - 访问器内部调用未声明变量（如
foo = 1）→ 报ReferenceError，防止意外挂载到全局
