关键在于正确设置描述符的特性、时机和目标；默认属性可删改遍历，需显式定义保护；数字键与字符串键等价但易混淆；writable与configurable职责不同，常需组合使用；存在性判断应使用hasownproperty或in而非!==undefined；freeze/seal影响整对象且不可逆。
关键不是“设了描述符”，而是设对了哪些特性、在什么时机、针对什么目标。很多 Bug 源于默认行为被误读，或多个描述符组合逻辑没理清。
别依赖字面量的默认值
对象字面量里写的属性，比如 { version: '1.0' }，默认是 configurable: true、enumerable: true、writable: true。这看起来方便，但恰恰埋下隐患：属性能删、能改、能被遍历，而你可能以为它“应该稳定”。需要保护时，必须显式用 Object.defineProperty 重定义，不能靠注释或约定。
- 数字键、计算属性名会自动转字符串，容易造成键名意外重复或类型混淆
-
{ [someObj]: 'x' }实际变成{ "[object Object]": "x" }，不是你想的引用键 - 属性名写成
42和"42"效果一样，但和Number(42)的语义无关
区分 writable 和 configurable 的职责
writable: false 只拦赋值，不拦删除；configurable: false 才真正锁死定义——删不掉、改不了描述符、也不能把数据属性变 getter。两者常要一起用，单独设一个容易漏防。
- 只设
writable: false→ 值改不了，但delete obj.prop还能成功（非严格模式返回false） - 只设
configurable: false→ 属性删不掉，但如果writable: true，值仍可覆盖 - 真正想做成“常量级”方法或配置项，就得
writable: false+configurable: false
存在性判断别用 !== undefined
属性存在但值为 undefined，或属性被设为 writable: false 且值就是 undefined，这时 obj.prop !== undefined 会误判为“不存在”。这不是描述符配错了，而是检查方式错了。
- 查自有属性是否存在 → 用
obj.hasOwnProperty('prop') - 查是否能在原型链上访问到 → 用
'prop' in obj - 查属性是否可枚举（比如出现在
Object.keys()里）→ 看enumerable值，而不是靠遍历结果反推
冻结/密封前先想清楚影响范围
Object.freeze 是整对象操作，会让所有自有属性变成 writable: false 且 configurable: false；Object.seal 只锁 configurable。它们不可逆，且作用于全部自有属性——哪怕你只想保护一个 API_URL，也会顺手锁死其他本该可写的字段。
- 轻量防护优先用单属性描述符，比如只给关键配置加
writable: false - 需要后期开放修改权限？定义时加上
configurable: true，否则再也改不回去了 - 冻结后新增属性会静默失败或抛错，但已有属性的值如果
writable: true，依然能改（除非 freeze 已执行）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
