关键在于正确设置描述符的特性、时机和目标；默认属性可删改遍历，需显式定义保护；数字键与字符串键等价但易混淆；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。两者常要一起用，单独设一个容易漏防。

Java Maven Common

Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。

下载

• 只设 writable: false → 值改不了，但 delete obj.prop 还能成功（非严格模式返回 false）
• 只设 configurable: false → 属性删不掉，但如果 writable: true，值仍可覆盖
• 真正想做成“常量级”方法或配置项，就得 writable: false + configurable: false

存在性判断别用 !== undefined

属性存在但值为 undefined，或属性被设为 writable: false 且值就是 undefined，这时 obj.prop !== undefined 会误判为“不存在”。这不是描述符配错了，而是检查方式错了。

立即学习“Java免费学习笔记（深入）”；

• 查自有属性是否存在 → 用 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 已执行）