configurable: false 并非删除属性，而是冻结其元信息，禁止 delete 和重定义描述符，但允许读写；动态注销需结合 defineProperty 替换、WeakMap 状态隔离与 getter 拦截实现。
通过属性描述符的 configurable: false 可以锁定属性的可配置性，但“动态注销”并非直接删除属性，而是利用 configurable 为 false 后无法被 delete、无法重定义（如修改 writable、enumerable、get/set）的特性，在运行期构建不可逆的业务约束——真正的“注销”需结合设计模式与运行时控制流，而非单纯依赖底层机制。
理解 configurable 的真实作用边界
configurable: false 并不等同于“删除”或“隐藏”，它只是冻结该属性的元信息：一旦设为 false，后续无法再调用 Object.defineProperty() 修改其描述符，也无法用 delete 移除该属性。但它仍可读写（若 writable: true），仍存在于对象中，仍可被访问。
- ✅ 允许：读取值、赋新值（若 writable）、调用 getter/setter
- ❌ 禁止：delete 属性、改 enumerable、改 writable（除非原本 writable: true）、改 get/set、再次 defineProperty 覆盖
- ⚠️ 注意：configurable: false + writable: true 的组合，意味着值可变但“身份不可变”——这正是实现“业务属性固化”的基础
用 Object.defineProperty 预埋可注销入口
在核心业务属性初始化时，不直接赋值，而是通过 defineProperty 显式声明，并预留一个受控的“注销开关”。例如，将关键字段（如订单状态、支付通道标识）封装为带 setter 的 accessor，内部通过标志位控制是否允许后续写入。
- 初始化时设置
configurable: true，允许后续调用defineProperty替换为只读+不可配置版本 - 提供
deactivate()方法，内部执行：Object.defineProperty(obj, 'prop', { value: undefined, writable: false, enumerable: false, configurable: false }) - 此举实质是“覆盖原属性”，用不可配置的占位值替代原有逻辑，达到语义上的“注销”效果
配合 WeakMap 实现跨实例状态隔离
若需在多个业务实例中独立管理注销状态（如不同订单对象各自注销自己的 paymentMethod），避免污染原型或全局状态，可用 WeakMap 存储每个实例的注销标记：
- 创建
const deactivatedProps = new WeakMap() - 在 getter 中检查：
if (deactivatedProps.get(this)?.has('paymentMethod')) return undefined - 注销操作只需：
deactivatedProps.get(this)?.add('paymentMethod')，无需触碰属性本身 - 这样既保持属性存在（兼容旧代码），又使访问返回预期“已注销”语义
谨慎处理原型链与继承场景
在类或构造函数中定义核心属性时，若希望子类实例也遵循同一注销规则，应避免在原型上直接定义 configurable: false 属性——这会导致所有实例共享同一不可逆状态。正确做法是：
- 在构造函数内对每个实例单独 defineProperty，确保注销行为实例级隔离
- 若必须在原型层统一控制，可将注销逻辑下沉至 getter 内部，通过实例私有字段（如
#isPropDeactivated）判断 - 禁止对从原型继承来的属性调用 delete 或 defineProperty 修改——这只会操作实例自身属性，易引发意料外的 shadowing
不复杂但容易忽略：configurable 是单向锁，设计之初就要规划好哪些属性需要“可注销”、哪些必须“永久存在”，并在首次定义时留出升级路径。真正的动态注销，靠的是组合 descriptor 控制 + 运行时状态 + 访问拦截，而不是寄希望于 delete 成功。
