07 对象与属性:藏在每个属性背后的描述符Copy Anchor Link

这一章讲什么Copy Anchor Link

JavaScript 里几乎所有东西都是对象:你的 React 组件、你操作的 DOM、你的 Express 服务,连数组和函数都是对象的一种¹。而对象在规范里的定义朴素得惊人: 一组「名字-值」对²。朴素定义底下却埋着一整套隐形机关—— 每个属性除了值,还配有一份「描述符」,三个属性决定它能不能改、 循环里看不看得见、删不删得掉。这章把这四个怪现象讲透: 赋值不报错也不生效;属性在 for...in 里凭空消失;delete 返回 false; 还有 Node.js 新手必踩的 process.env.FOO = { a: 1 } 变出 '[object Object]'。

顶层全景:一个属性的完整档案Copy Anchor Link

  你写的:        drawer.contents = 'tax documents'
                     │
  引擎看到的:     属性名 'contents'
                     │
                     ├─ 是哪种属性?
                     │    ├─ 数据属性 → 档案里存 [[Value]] 和 [[Writable]]
                     │    └─ 访问器属性 → 档案里存 [[Get]] 和 [[Set]](读写都执行函数)
                     │
                     └─ 三个通用属性(取值都是 true/false):
                          [[Enumerable]]   为 false → for...in / Object.keys() 里隐身
                          [[Configurable]] 为 false → 删不掉、描述符本身也锁死
                          (外加数据属性专属的 [[Writable]] 为 false → 值改不动)

  图说:你赋值的对象不是一个「槽位」,是一整套带属性的档案;
        三个属性平时都为 true,所以无感;一旦有人(或宿主)动过属性,怪事就来了。

核心原理Copy Anchor Link

3.1 对象:运行时才能定形状的动态映射Copy Anchor Link

和 Java、C++ 对比着看最清楚。在那些静态语言里,对象是编译期就定死的结构: 你在类里声明字段,编译器记住每个字段在内存里的偏移,之后每个实例都按这张图 排布;想加字段?改类定义,重新编译³。

JavaScript 反过来:对象是动态的映射(dynamic map),运行中随时可以加字段—— filingCabinet.contents = 'Tax Documents' 一句话,字段就有了⁴。 动态性带来静态语言做不到的模式:按运行时条件逐步组装对象、从多个来源混入功能、 甚至给第三方库的对象打补丁⁵。

代价同样在 3.1 节埋下:C++ 读一个字段是「跳到已知偏移,读字节」; JavaScript 是「在这个动态集合里搜索」。引擎事先不知道对象长什么样, 知道了也可能随时变——不理解这个搜索过程和它的内部结构, 就是 JavaScript 性能问题的主要来源⁶。搜索怎么加速?那就是 08 章的原型链 和 10 章的隐藏类与内联缓存。

3.2 两种属性:存值的,和跑代码的Copy Anchor Link

规范把属性分两类,区别在「取值这个动作怎么完成」⁷:

数据属性(data property)就是直觉的样子:值存在档案里([[Value]]), 你存什么取什么,无计算、无副作用⁸。drawer.contents = 'invoices' 之后 读回来就是 'invoices'。

访问器属性(accessor property)是特务:档案里存的不是值, 是两个函数——读取时跑 getter(取值函数),赋值时跑 setter(赋值函数)。 从外部看它和普 通属性一模一样,但每次读写背后都有代码在执行: 可以算、可以顺带改别的属性、可以有副作用⁹。

主线例子:一个会自己算账的抽屉。 照原书的例子走一遍——

const dynamicDrawer = {
  _actualContents: ['receipt-001.pdf', 'receipt-002.pdf', 'tax-form.pdf'],
  get contents() {                       // 读取时:不返回值,运行这段代码
    return this._actualContents.length > 0
      ? `${this._actualContents.length} documents`
      : 'empty';
  },
  set contents(newItem) {                // 赋值时:不覆盖,运行这段代码
    if (typeof newItem === 'string') {
      this._actualContents.push(newItem);
    }
  }
};
console.log(dynamicDrawer.contents);       // '3 documents'  ← getter 算的
dynamicDrawer.contents = 'invoice.pdf';    // setter 执行:push 进数组
console.log(dynamicDrawer.contents);       // '4 documents'

每一步旁边都有具体状态:读之前 _actualContents.length 是 3,getter 返回 '3 documents';赋值 'invoice.pdf' 没有覆盖任何东西,而是被 setter 追加进数组,length 变 4,第二次读取返回 '4 documents'¹⁰。

访问器能造成「成员访问也会触发副作用」的惊讶——C++ 来的开发者最不习惯这个 (那里的成员访问永远直连内存)。原书的建议:刻意地用访问器; 拿不准,你就不该用它¹¹。

3.3 怪现象之王:process.env 为什么吃掉你的对象Copy Anchor Link

把访问器换成 Node.js 真实场景,怪现象立刻有了生产级的重量:

process.env.FOO = { a: 1 };
process.env.FOO;    // '[object Object]' ???

赋值明明「成功」了:不报错,运行时不吭声。读回来却是一串莫名其妙的字符串¹²。 谜底:process.env 是个特殊对象,它的每个属性默认都是访问器, setter 拿到你赋的值后,总是先做字符串转换再存¹³——对象转字符串就是 06 章学过的 '[object Object]'。理解了「属性有两种、访问器会跑代码」, 这个谜就从「见鬼」降级成「哦,setter」;不理解,就会在 Stack Overflow 上 浪费一个下午¹⁴。这本书的技术编辑在审稿时质疑过「普通开发者不知道 [[Get]]/[[Value]] 不也过得好好的?」——这三个怪现象(加上 3.5 的 三个属性怪现象)就是作者的答辩¹⁵。

3.4 双括号记号:规范的「内部档案」长什么样Copy Anchor Link

先认一下规范的语言。书里大量出现 [[Value]]、[[Get]]、[[Prototype]] 这样的双括号记号:它来自 ECMAScript 规范,用来区分「引擎内部的机械」 和「你写的代码」¹⁶。规矩是:

• 内部方法(internal methods)是引擎执行的操作:你写 obj.foo, 引擎内部执行 [[Get]];
• 内部槽(internal slots)是引擎用来存数据的位置:[[Value]]、[[Prototype]] 都是槽——档案袋,不是函数¹⁷。

你永远不会在代码里写 obj.[[Get]]('foo'),但这些记号是读规范、读 V8 文档的 通行证,本拆解后面几章会反复用到。

3.5 三个属性,三类怪现象Copy Anchor Link

描述符的全貌出来了:数据属性六个档案格([[Value]]、[[Writable]]、 [[Get]]/[[Set]] 不适用、[[Enumerable]]、[[Configurable]]), 访问器属性换成 [[Get]]/[[Set]] 两格;其中 [[Value]]/[[Writable]] 与 [[Get]]/[[Set]] 互斥——一个属性不可能既是数据属性又是访问器¹⁸。

三个属性各自制造一类经典 bug,书里列得整整齐齐¹⁹:

属性一:writable —— 值为 false 时,赋值静默失败或抛错, 取决于运行模式:严格模式(strict mode)下抛 TypeError,松散模式(sloppy mode) 下安安静静地什么都不发生²⁰。这就解释了「我写 obj.foo = 'bar', 没报错,值却没变」——去查 writable²¹。

属性二:enumerable —— 值为 false 时,属性存在但隐身: for...in 和 Object.keys() 都列不出它,直接访问却好好的²²。 这就解释了「属性明明在,循环里就是看不见」²³。

属性三:configurable —— 值为 false 时,delete 失灵, 而且 Object.defineProperty() 也不能再改它的档案:描述符整个锁死²⁴。 注意 writable 和 configurable 管的是两回事: 值能不能改 vs 档案能不能改。一个属性可以「值能改但档案锁死」 (可写但不可配置),也可以反过来²⁵。

想查看任何属性的档案,一句话:Object.getOwnPropertyDescriptor(obj, 'prop'), 返回 { value, writable, enumerable, configurable } 或 { get, set, enumerable, configurable }²⁶。书里的金句:平时永远用不到它; 但怪事发生时,它能让你几秒钟定位问题,而不是搜几小时症状²⁷。

3.6 默认值陷阱:同一个属性,两种出生待遇Copy Anchor Link

最容易踩的坑来了:同样的三属性,默认值随创建方式不同而不同²⁸。

const a = { prop: 'value' };                 // 字面量创建
Object.getOwnPropertyDescriptor(a, 'prop');
// { value: 'value', writable: true, enumerable: true, configurable: true }

const b = {};
Object.defineProperty(b, 'prop', { value: 'value' });   // defineProperty 创建
Object.getOwnPropertyDescriptor(b, 'prop');
// { value: 'value', writable: false, enumerable: false, configurable: false }

字面量创建,三个属性默认全开;Object.defineProperty() 创建, 你不显式写 true,默认全关²⁹。规范的心态是:既然你绕远路用 defineProperty,就当你想要一个受保护的、受限的属性³⁰。 配套还有个 Object.defineProperties()(带 s),一次定义一批, 两 者在档案含义上完全等价,只是一次定义多个更高效——为什么高效,要等 10 章的 隐藏类才讲得清³¹。

访问器属性的档案形状也不同:没有 value/writable,读出来是 undefined; 取而代之的是 get/set 两个函数³²。用 getOwnPropertyDescriptor 一看便知属性是哪种。

3.7 承上启下:档案管「找到之后」,找的过程在下一章Copy Anchor Link

描述符管的是「属性找到之后怎么对待你」。但还有个更根本的问题: drawer.toString() 这个方法,你的 drawer 上根本没有定义,它从哪冒出来的? 答案:继承——属性不一定在自己身上,引擎有一条专门的查找路线 (原型链)来决定一个属性到底从哪来³³。档案 + 查找路线,两件 事合起来 才是一个属性的完整一生。查 找路线是下一章(08)的主角。

3.8 原书抽屉例子的完整展开:一个属性的四个动作Copy Anchor Link

07 章的原书例子是一只「抽屉」(drawer),值和状态齐全, 值得把它的四个动作从头到尾走一遍,每一步旁边都有具体状态³⁴:

const drawer = {
  width:      { value: 16, unit: 'inch' },   // 对象值
  height:     { value: 13, unit: 'inch' },
  depth:      { value: 28, unit: 'inch' },
  serialNumber: 1234567890123456789n,         // BigInt 值
  locking:    true,                          // 布尔值
  contents:   'tax documents'                // 字符串值
};

读:drawer.contents → 'tax documents'——数据属性的读, 就是档案里取 [[Value]],无计算、无副作用³⁵。 写:drawer.contents = 'invoices' → 再读就是 'invoices', 档案里的 [[Value]] 被替换³⁶。 查档案:Object.getOwnPropertyDescriptor(drawer, 'contents') → { value: 'invoices', writable: true, enumerable: true, configurable: true }—— 字面量创建,三属性全开³⁷。 动态版:dynamicDrawer(3.2 节)的 contents 换成访问器后, 同样的四个动作,读和写背后都跑了代码,档案形状从 { value, writable, ... } 变成 { get, set, ... }³⁸。

四个动作里藏着本章的真正主题:属性的「外表」完全相同 (drawer.contents 永远是这个写法),「内在」却可以一个是存值、 一个是跑函数——而区分它们的方法,只有 getOwnPropertyDescriptor 这一扇窗。这就是技术编辑质疑「普通开发者不需要懂描述符」时, 作者用 process.env 谜案作答的原因:你可以不懂,直到你撞上。

3.9 本章的章末坐标Copy Anchor Link

5.2 节在原书里是对象章的地基段,它的出口通向下文三处³⁹:

• 「档案管找到之后,查找管怎么找到」——5.3 的原型链,我们的 08;
• 「同形状的多属性定义更高效」——5.8 的隐藏类,我们的 10;
• 「访问器会跑代码」的警告贯穿始终——5.6 的 Proxy 把它推到极限,我们的 09。

三处出口里,5.2 自身回答的问题其实只有一个: 「一个属性除了值,还藏着什么?」 答案是六格档案与三个 true/false。 这九样东西平时全不可见,却各自对应一类生产怪现象; 而 Object.getOwnPropertyDescriptor 是唯一的透视窗—— 书里那句「几秒钟定位,而不是搜几小时症状」,就是为它写的广告词⁴⁰。

3.10 一句话记住本章:属性是「带档案的值」Copy Anchor Link

压缩成一句可以带走的话:JavaScript 的属性从来不只是「值」, 它是「值 + 六格档案」的组合体;赋值、枚举——也就是逐个列出成员——、删除这些日常动作, 全是档案里某几格的 true/false 在起作用。 记住这句, 四类怪现象(静默失败、循环隐身、delete 失灵、process.env 吃对象) 就从「玄学」降级为「查档案」——而查档案的工具 Object.getOwnPropertyDescriptor,从 ES5(2009)起就没换过。

3.11 描述符与冻结(freeze)家族:同一张档案的多属性操作Copy Anchor Link

边界与局限里提过「冻结家族」(Object.freeze 等把属性一次性锁死的三个 API)没展开,这里补一笔(标注:这一小节的三个 API 原书未细讲,属我们依据描述符机制的补充)⁴¹: Object.preventExtensions(obj) 禁止加新属性(档案不可新增)、 Object.seal(obj) 在此外再禁止删(档案的 configurable 全锁)、 Object.freeze(obj) 再再禁止改值(档案的 writable 全锁)。 三档递增,全是「一次性改档案」的语法糖——懂了 3.5 的三个属性, 冻结家族就不需要背:它们只是把三个属性批量锁死的封装。 配套的还有两道常见面试题的答案:「为什么 freeze 之后改值静默失败 (或严格模式下报错)?」——writable 批量变 false,回到 3.5 节; 「为什么 freeze 之后还能改嵌套对象的字段?」——freeze 只锁 第一层档案的那三个属性,嵌套对象的档案不归它管,想深冻要自己递归。 两道题的答案都在同一格 [[Writable]] 上,这就是机制学习的复利: 一个格子,解一串题。

最后把 07 章挂回全书主线:描述符是语言层的构造(规范里的 六格档案,所有引擎必须实现同一套规则),而「档案怎么存」是 10 章 隐藏类的话题,「档案沿链怎么查」是 08 章原型链的话题。 语言层给你档案的定义,实现层给你档案的速度—— 07 章站在两者的分界线上,左边是「属性是什么」,右边是「属性怎么飞」。

作者的判断与证据Copy Anchor Link

有证据的判断:

• 三属性的行为(writable 静默失败/抛错、enumerable 隐身、configurable 锁死) 是规范事实,书中逐一举例并给出 getOwnPropertyDescriptor 的输出⁴²。
• 字面量 vs defineProperty 的默认值差异,有代码输出为证⁴³。

作者的主张:

• 「process.env 谜案」的机制解释(每属性默认是访问器)是作者以 Node.js 核心成员身份给出的实现内情,属一手证词⁴⁴。
• 「拿不准就别用访问器」是实践立场,反方(访问器利于封装)书中未辩论。

判断(我们的,不是书里的): 描述符的价值不在日常使用,而在排障时有名字可喊—— 「这个属性 configurable 是 false」比「它删不掉」在沟通与检索上都高一个量级; 本章把三个属性翻译成三种可观察现象(静默失败/循环隐身/delete 无效), 是全书「把规范词汇变成排障词汇」的示范。 如果错,会错在: 在高度依赖元编程的代码库(ORM、状态管理)里,描述符不是 排障词汇而是日常 API,本章「平时不用管」的定调会低估使用频率——但机制本身不变。

边界与局限Copy Anchor Link

• 双括号档案是语言规范层的描述方式;V8 实际不按六格存(它走隐藏类 + 描述符数组,见 10 章),书里也注明了这点⁴⁵。
• 属性遍历的全部 API(for...in、Object.keys、getOwnPropertyNames、 含 symbol 的 getOwnPropertySymbols)之间的差别,原书没列表,只在 enumerable 一处带过。
• Object.freeze/Object.seal/Object.preventExtensions 这三个 「一次锁定多个属性」的 API 本章完全没出现——它们其实就是描述符属性的一次性版本。
• process.env 的具体行为属 Node 实现,其他宿主不保证。

可带走的Copy Anchor Link

1. 对象 = 动态的键值对集合;引擎事先不知道形状,找属性要「搜索」——性能话题的种子。
2. 属性分两种:数据属性存值;访问器属性存两个函数,读写都会跑代码(可能有副作用)。
3. process.env.FOO = {} 变 '[object Object]':访问器 setter 做了字符串转换。
4. 三属性:writable(值)、enumerable(列表)、configurable(档案本身); 对应三类怪现象:静默失败、循环隐身、delete 失灵。
5. 默认值陷阱:字面量全 true;defineProperty 不显式写就全 false。
6. Object.getOwnPropertyDescriptor() 是调试这三类怪现象的第一工具。
7. 双括号记号([[Get]]、[[Value]])是规范的内部机械,读规范前先认它。
8. 描述符管「找到之后」;「怎么找到」是下一章的原型链。

原文地图Copy Anchor Link