JavaScript 中严格模式下 ES5 对象属性名与访问器冲突的处理规则

在 es5 严格模式下，对象字面量中若同时声明同名的数据属性与 getter/setter，后者会覆盖前者（或反之），导致不可预期行为；es5 不允许共存，但不会报错，而语义已被破坏。

在 ECMAScript 5（ES5）规范中，对象的每个属性名在内部对应唯一的“属性描述符”（Property Descriptor）。该描述符只能是以下两种之一：

• 数据描述符（Data Descriptor）：含 value 和 writable 等字段，对应普通赋值属性（如 p: 5）；
• 访问器描述符（Accessor Descriptor）：含 get 和/或 set 函数，对应 getter/setter。

关键规则：一个属性名在同一对象中不能同时拥有数据描述符和访问器描述符。当使用对象字面量定义时，ES5 引擎按声明顺序依次处理各属性，并对同名属性执行覆盖（overwrite） —— 后出现的定义完全取代先出现的，无论其类型是数据还是访问器。

因此，你提供的第一个示例：

"use strict";
let obj = {
  p: 5,
  get p() { console.log("in getter"); },
  set p(v) { console.log("in setter: ", v); }
};

在 ES5 严格模式下合法但危险：p: 5 首先创建数据属性；随后 get p() 覆盖为访问器属性（仅含 getter）；最后 set p(v) 再次覆盖，最终 obj.p 仅保留 setter（无 getter），此时读取 obj.p 将返回 undefined（因 getter 已丢失），且不抛错。

类似地，你的 Ex 2：

let obj2 = {
  get p() { return 6; },  // ① 创建 getter
  p: 5,                    // ② 覆盖为数据属性（值为 5）
  set p(v) { /*...*/ }     // ③ 覆盖为仅 setter 的访问器（无 getter！）
};
console.log(obj2.p); // → u
ndefined（读取无 getter 的 setter-only 属性）

执行顺序决定了最终属性类型：最后定义的 set p 使 p 成为仅有 setter 的访问器属性，而 ES5 规定：对仅含 setter（无 getter）的属性执行读取操作时，返回 undefined，且不抛异常（即使在严格模式下）。

✅ 正确实践：始终分离存储与接口
应使用私有命名约定（如 _p）存储实际值，并通过独立的 getter/setter 控制访问：

"use strict";
const obj = {
  _p: 5,
  get p() {
    console.log("in getter");
    return this._p;
  },
  set p(value) {
    console.log("in setter:", value);
    this._p = value;
  }
};

console.log(obj.p); // "in getter" → 5
obj.p = 10;         // "in setter: 10"
console.log(obj.p); // "in getter" → 10

⚠️ 注意事项：

• ES5 无语法错误，但逻辑失效：重复同名属性不会触发 SyntaxError 或 TypeError，掩盖了设计缺陷；
• 严格模式 ≠ 安全检查："use strict" 在此场景下不阻止覆盖行为，仅禁止某些不安全操作（如 with、静默失败赋值等）；
• ES6+ 行为不同但更复杂：ES6 允许同名定义，但覆盖规则更精细（如 getter + data → data 保留；getter + setter + data → 最终为 setter，读取返回 undefined），仍不推荐混用；
• 兼容性验证建议：若需真实测试 ES5 行为，可使用 Babel REPL 配置 @babel/preset-env 目标为 { esmodules: false, targets: { ie: "11" } }，或运行于 IE11 / Node.js v0.12 等纯 ES5 环境。

总结：在 ES5（及后续版本）中，永远不要在同一个对象字面量中为同一名称既声明数据属性又声明 getter/setter。这是设计层面的根本冲突，而非语法限制。采用 _(name) 存储 + 显式访问器的模式，是清晰、可靠且跨版本安全的最佳实践。