javascript对象字面量看似简洁，实则隐含属性描述符默认行为、计算属性名类型转换、数字键字符串化等细节；属性描述符需通过defineproperty操作，configurable和enumerable常被误解；存在性判断应避免undefined比较，优先用hasownproperty和in；浅拷贝共享嵌套引用，json序列化丢失函数/symbol/循环引用，深拷贝须处理类型与循环。
JavaScript对象看似简单，但字面量写法、属性描述符控制、存在性判断和拷贝逻辑这四块，藏着大量易踩的隐性坑。真正用好对象，关键不是“能写出来”，而是清楚每一步背后的行为边界和引擎约束。
对象字面量：别被简洁表象骗了
字面量 { a: 1 } 是最常用写法，但它默认创建的是可配置、可枚举、可写的普通数据属性——这点常被忽略。ES6 支持计算属性名，比如 { [key]: value }，但 key 必须是字符串或 Symbol；若传入对象或函数，会先调用 toString() 转成字符串（如 { [{}]: 'x' } 实际变成 { "[object Object]": "x" }）。另外，属性名即使写成数字（如 { 42: "answer" }），也会被自动转为字符串键，所以 obj[42] 和 obj["42"] 等价。
属性描述符：四个特性缺一不可
每个属性背后都有 [[Configurable]]、[[Enumerable]]、[[Writable]] 和 [[Value]]（数据属性）或 [[Get]]/[[Set]]（访问器属性）这些内部特性。它们不能直接读取，只能通过 Object.defineProperty() 或 Object.getOwnPropertyDescriptor() 操作。常见误区包括：
- 把 configurable: false 当作“锁死属性”，其实它只禁止 delete、重定义描述符、数据属性 ↔ 访问器属性转换，但不影响值修改（只要 writable 为 true）
- 误以为 enumerable: false 就等于“不存在”，其实 in 操作符和 hasOwnProperty() 仍能检测到，只是 for-in 和 Object.keys() 会跳过
- 使用 Object.defineProperty() 给已有属性加 getter/setter 时，必须显式设 configurable: true，否则后续无法再改
存在性检查：三个操作符行为完全不同
判断一个属性是否“在对象上”有三种方式，但语义差异极大：
- "prop" in obj：检查对象及其整个原型链，只要任意一层有该属性名就返回 true
- obj.hasOwnProperty("prop")：只查对象自身，不查原型，但对继承来的不可枚举属性也返回 false
- obj.prop !== undefined：不可靠！因为属性值本身可能是 undefined，此时会误判为“不存在”；更糟的是，如果属性被定义为 writable: false 且值为 undefined，这个判断依然失效
安全做法是优先用 hasOwnProperty() 判断自有属性，用 in 判断是否可访问，避免用值比较做存在性断言。
对象拷贝：浅、深、循环引用，一个都不能少
拷贝不是“复制内容”那么简单，而是涉及内存引用与结构重建：
- 浅拷贝陷阱：Object.assign()、展开运算符 {...obj}、构造新对象赋值，都只复制第一层属性引用。嵌套对象或数组仍共享内存，改子项就影响原对象
- JSON 方法局限：JSON.parse(JSON.stringify(obj)) 会丢掉函数、undefined、Symbol、Date、RegExp、Map/Set、循环引用，且 NaN、Infinity 变成 null
- 手写递归深拷贝风险：没处理循环引用会爆栈；没区分数组与普通对象，可能把数组当普通对象遍历导致索引丢失；没过滤原型属性，可能拷贝到不该存在的方法
- 推荐方案：业务中若需可靠深拷贝，优先用成熟库（如 lodash 的 cloneDeep）；若自己实现，必须用 WeakMap 缓存已拷贝对象来破循环，且显式判断 Array.isArray() 和 null/Date/RegExp 等特殊类型
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
