作为一个整天跟 JavaScript 打交道的前端开发我越来越觉得,对象这东西就是 JS 的命根子。你要是能把对象搞透什么框架、源码、工程化看着都跟玩拼图似的。但我也发现很多写了两年多的开发者对象还停留在“{ } 存东西”的层面一问到原型链、属性描述符、深浅拷贝就开始含糊其辞。这篇博文我不打算给你念文档而是从一个实际项目里踩坑、爬坑的角度把从创建一个对象到理解它底层原理的完整路径捋一遍。没有废话全是实操里提炼出来的东西。1. 对象是什么先搞清楚它为什么是 JS 的“一等公民”1.1 万物皆可对象JS 世界的基本设定很多刚入门的朋友会把对象理解成“键值对的集合”这个说法没错但特别容易误导人。准确来说对象是一组无序属性的集合属性名是字符串或 Symbol属性值是任意类型的数据。这听起来简单但你要明白一个底层逻辑JS 这门语言本来是没有“类”的概念的它的一切高级特性都是基于对象模拟出来的函数是对象数组是对象正则也是对象。这就意味着你对对象的理解深度直接决定了你对整个语言的掌控程度。我接手过好几个别人留下的老项目里面大量代码是用var person {}这种方式散装定义的属性满天飞方法到处挂。之所以这么乱核心原因就是没搞懂对象在 JS 里的定位。当你明白“几乎所有数据形态的顶层都是对象”时你就会下意识地思考这个东西该不该合并那个方法该不该挂到原型上全局变量该怎么收敛。这个认知转变是我觉得新手到进阶最关键的坎。1.2 引用类型变量里装的根本不是对象这是我认为先要从底层刻进脑子里的认知。你写let obj { name: 锋哥 }的时候变量obj里存的并不是那个对象本身而是对象在内存堆区里的一把“门钥匙”引用地址。常规的原始类型像字符串、数字值就存在栈上你复制一个给别的变量是值拷贝互不影响。但对象不一样你let obj2 obj只是把这把钥匙复制了一份两把钥匙开的还是同一扇门。这个特性是后面所有坑的根源。我在给团队做 Code Review 时最常见的 bug 就是有人以为const obj2 obj就完成了一次复制结果改obj2的时候把obj也改了。很多新手会惊讶但如果你能理解引用类型的存储方式你会觉得不惊讶才是怪事。内存模型不是高深的理论它是你理解深浅拷贝、性能优化、意外修改等一切问题的基石。2. 创建对象的几种姿势别只会字面量和new Object()更别乱用new2.1 字面量日常最常用但有个细节多数人没注意对象字面量{ }是日常中最推荐的创建方式没有之一。它的优势是直观、简洁、性能好V8 引擎对字面量创建的对象做了大量优化。但这里有个细节新手一般不会注意属性名的引号问题。比如{ user-name: 锋哥 }这种带连字符的键必须加引号否则就报错而{ name: 锋哥 }这种合法的标识符加不加引号都一样。还有一个实战经验当你需要根据条件动态添加属性时别用拼字符串的方式搞出十万个ifES6 的展开运算符和计算属性名computed property是特别优雅的解法。举个例子比如你要根据用户权限决定对象里放哪个字段const baseInfo { id: 1, name: 锋哥 }; const permission isAdmin ? { role: admin } : { role: guest }; const finalUser { ...baseInfo, ...permission };这个看似简单的展开运算实际就是一种浅合并。你后面会经常用到但那时你会发现它也有坑——嵌套对象还是会被共享。这就是我们从创建对象过渡到原理层面的第一步不是所有的复制都是深层的。2.2 工厂函数、构造函数和Object.create绕不开的历史包袱与进化老代码里经常能看到这种写法function createPerson(name) { return { name: name, sayHi: function() { console.log(hi); } }; }这叫工厂函数它的问题是每次调用都会在内存里生成一个全新的sayHi函数如果创建一万个对象就有一万个不同的函数实例。这在早期内存紧张的时代是浪费于是就有了构造函数加原型链的解法function Person(name) { this.name name; } Person.prototype.sayHi function() { console.log(hi); };new关键字创建对象时JS 引擎会悄悄做几件事。你以为new就是执行一下函数根本不是。它会在函数内部隐式创建一个新对象让这个对象的原型指向构造函数的prototype然后再把构造函数里的this绑定到这个新对象上最后如果你没显式返回对象就返回这个刚创建的实例。这个阶段ES6 引入了class它本质是构造函数的语法糖写起来更清晰但底层机制还是那套。所以我的建议是日常业务代码直接用class没毛病但你心里得清楚它底层还是在走原型链那一套。至于Object.create(null)这种创建“纯净对象”的方式我在做字典映射、哈希表场景时会用它能避免因为原型链上的属性导致逻辑误判比如{}在控制台输入toString你是能访问到的而Object.create(null)创建的对象是真正意义的“裸对象”。2.3 不同方式的选型对比一张表看懂什么时候用哪种创建方式核心特点适用场景注意事项对象字面量{ }最简洁、性能优化好普通数据存储、常量配置创建单例对象不要用new工厂函数封装创建逻辑返回对象需要复杂逻辑生成实例注意每实例副本内存开销大构造函数newprototype方法共享在原型上节省内存需要创建大量相同结构的实例必须用new调用否则this指向全局class语法糖结构清晰适合现代业务面向对象编程还是原型那套别误以为加了真正类Object.create()自定义原型对象继承指定对象、创建裸对象参数为null时得到无原型对象这张表是我每次给团队做培训时必讲的清单。你不一定全背下来但心里要有张地图在哪块业务用哪种姿势踩了什么坑往哪方面排查。比如规格大的数据列表就别用工厂函数批量建对象内存一上去页面就卡换成构造函数挂原型的方式能顺畅得多。这也是为什么我从不让团队在forEach里写{ name: xxx }去创建一万个对象能复用结构的就应该复用。3. 核心原理拆解属性特征、原型链、this 绑定三座大山一次翻越3.1 属性描述符对象属性的“隐藏设定”超乎你想象很多人以为属性就是“名字加值”用了好几年才发现 JS 的每个属性都是带着“特性”的。什么叫特性比如这个属性能不能被重新赋值能不能被删除遍历的时候会不会出现。这就是属性描述符Property Descriptor。你直接看Object.getOwnPropertyDescriptor就能调试出一堆细节const obj { name: 锋哥 }; console.log(Object.getOwnPropertyDescriptor(obj, name)); // 输出: { value: 锋哥, writable: true, enumerable: true, configurable: true }四个属性分别对应值、可写性、可枚举性、可配置性。平时我们开发不会太注意但一旦涉及框架源码、数据响应式这玩意儿就无比关键。比如 Vue 2 的响应式就是通过Object.defineProperty去劫持属性的get和set。你在改框架配置时遇到明明弹出一个属性不可修改多半就是writable: false或configurable: false在作怪。这里有个实用技巧用Object.preventExtensions、Object.seal、Object.freeze可以控制对象的可扩展性、不可删除属性和不可修改属性。我一般对常量配置对象会做Object.freeze防止别人在代码里偷偷改了全局公共配置排查半天查不到。这三个方法的使用场景区分要清楚防扩展是“不能加新属性”密封是“不能加也不能删”冻结是“彻底只读”。3.2 原型链为什么“对象能使用方法”不是理所当然的先问一个最容易被当成废话的问题你创建一个空对象{}然后用.toString()为什么能用你并没有定义这个方法。答案就是原型链。每个对象内部都有一个隐藏属性在规范里叫[[Prototype]]指向另一个对象。当访问一个属性时当前对象自己没有引擎就会沿着这条链往上找直到找到或者到达最顶层的null。很多朋友学这里会跟“构造函数”的概念混淆。这里要理清一个关键点所有实例对象的原型指向的是构造函数的prototype对象而不是构造函数本身。也就是说person.__proto__ Person.prototype这是两条完全不同的线索。这在内存共享上意义重大。你把方法放在Person.prototype.sayHi上一万个实例访问的都是同一个函数地址这就是代码优化的核心思想。继承本质上也是在操作这条链比如让Student.prototype继承Person.prototype那么学生实例查找方法时会先找自己找不到就去Person.prototype里找。理解到这一层你去读框架里各种“继承”、“多态”的代码就不会发怵。值得注意的是规范不推荐直接用__proto__更推荐Object.getPrototypeOf和Object.setPrototypeOf。但__proto__在浏览器里依然被广泛支持阅读老代码时会频繁见到。你要把它当“通往原型对象的快捷方式”理解但写新代码最好规范些。以下是一个极简原型链的示意function Animal(name) { this.name name; } Animal.prototype.sayName function() { console.log(this.name); }; function Dog(name) { Animal.call(this, name); // 核心把父构造函数当普通函数调用传 this 进去 } Dog.prototype Object.create(Animal.prototype); // 核心重新指定原型 Dog.prototype.constructor Dog; // 修复 constructor 指向 const d new Dog(旺财); d.sayName(); // 旺财这种手写继承的方式虽然老但最能看清原型链是怎么拼接起来的。如果你用class的extends看到编译产物觉得复杂回头再看这段就全明白了。3.3 this 绑定调用位置决定一切箭头函数是例外很多初学者对 this 的恐惧其实源于把静态作用域和动态绑定搞混了。普通函数的this是在调用时确定的谁调用的它它就指向谁。这句话值得用十个项目去验证。比如const user { name: 锋哥, say() { console.log(this.name); } }; user.say(); // 锋哥 const fn user.say; fn(); // undefined这里 this 丢失了第二个例子中fn调用时没有对象前缀this在非严格模式下会指向全局对象。这就是面试和实际开发里最常遇到的坑——方法提出来单独调用this就错了。解决方案有很多fn.call(user)、fn.bind(user)、箭头函数捕获但核心是你得先意识到这里有坑。箭头函数的特性是它本身没有this它用的this是定义时外部作用域的那个。我在做定时器、事件回调时特别喜欢用箭头函数因为不需要再临时const self this了。但这也带来一个新的注意点箭头函数不能作为构造函数使用也不能依赖 arguments 对象要用 rest 参数。最底层再看一眼new和 bind。new里构造函数被调用时this指向新对象bind返回一个新函数这个函数的this被永久锁死。这四个规则默认绑定、隐式绑定、显式绑定、new绑定就是全部。优先级上new最高其次是显式绑定再是隐式绑定最后是默认绑定。4. 运行机制实战遍历、合并、拷贝、比较每一个都是硬碰硬4.1 对象的遍历与检测for...in、Object.keys、Reflect.ownKeys到底用哪个原型的知识如果只是“能理解”而不“会用”那是没用的。这里正好有最典型的场景遍历。新手用for...in遍历对象一不小心会把原型上扩展的属性也遍历出来。永远记住for...in是遍历所有“可枚举的自身属性加继承属性”的。如果你不清楚这一点给Object.prototype挂过扩展那么所有 for...in 都会中招。Object.keys则安全且常用它只返回自身可枚举属性。但也有局限它无法识别 Symbol 类型的键。如果你需要处理 Symbol 键用Reflect.ownKeys可以拿到全部自身属性的键包括不可枚举和 Symbol。这是我强烈推荐的方法。举一个实际场景你想拷贝一个对象但对象里可能有 Symbol 键作为内部标记用Object.keys加Object.assign会把标记丢得一干二净。你自己写的代码还好如果是解析第三方返回的数据结构这个坑就特别隐蔽。判断一个对象是否有某个属性也很有讲究。obj.name的做法如果属性值本身是undefined或者属性来自原型链会干扰判断。最稳妥的是Object.prototype.hasOwnProperty.call(obj, name)只查自身。现在也有更好的Object.hasOwn(obj, name)这个 API 是标准提供的语义更清晰。ES2022 之后的代码里我建议直接用Object.hasOwn。关于空对象的判断很多老代码写JSON.stringify(obj) {}这种方式在属性值为undefined、函数、Symbol 时会失真。正确的姿势是组合Object.getOwnPropertyNamesObject.getOwnPropertySymbols或者通过Reflect.ownKeys(obj).length 0来判断。4.2 深浅拷贝为什么说“拷贝”这件事水很深以及三个一次性解决的办法深浅拷贝的问题是每个 JS 开发者都要面对的。先说浅拷贝Object.assign和展开运算符{...obj}都是浅拷贝。浅拷贝的意思是对于对象里的基本类型属性会完整复制但如果是嵌套的对象那么新对象里那个属性还是指向同一个地址。举个典型的业务场景你有一个用户对象里面有个address是对象你用{...user}复制了一份然后修改新对象的address.city老用户的address.city也跟着变了。这种问题在表单回填、取消编辑的场景特别常见。深拷贝的解决主流有三招。第一招是JSON.parse(JSON.stringify(obj))简单粗暴但缺点是undefined、函数、Symbol 值会丢失Date 会变成字符串RegExp 会变成空对象循环引用会直接报错。所以它只适合纯数据结构的拷贝。第二招是structuredClone这是现代浏览器原生 API能处理循环引用、Date、Map、Set比 JSON 方案强很多是目前的首选但要考虑兼容性。第三招是自己写递归函数用 WeakMap 处理循环引用这是最彻底、最可控的方案适合特殊定制。这里我必须强调一个经验团队里如果有一个公共的深拷贝函数不要自己实现第三招否则大概率写出一个内存爆炸、循环引用崩掉的轮子。能使用原生能力就优先使用框架里一般也自带了能调用的 deep clone 工具。自己写递归的唯一理由是你需要处理特殊类型比如保留原型链上的方法。4.3 对象比较与解构两个看起来一样的对象为什么永远不相等对象比较是另一个高频困惑这个对象和另一个对象内容长一样但a b却是false。因为比较的是引用地址。只有当你真的需要判断两个对象内容是否相等时可以手写一个遍历比对函数或者借助工具库的isEqual。日常开发中判断引用是否相同用于优化性能是合理的比如避免重复渲染时判断数据是否变更但判断内容是否相同要注意性能开销。解构赋值也是操作对象时离不开的。从嵌套结构中提取属性时要留意变量名冲突和默认值写法。const { name, age 18 } user;这种写法能在属性缺失时给默认值但有一个坑如果name的值本身是null默认值不会生效它照样是null。这在解析接口数据时特别容易翻车。另外一个符合实操习惯的经验是 rest 解构。比如你要排除对象中的某个敏感字段再去传给接口可以这样const { password, ...rest } user;这是很干净的排除写法不需要你再 delete 一个字段。这种技巧在框架状态管理里太常用了。5. 常见问题排查与避坑速查稳、准、狠地定位对象的真实身份5.1 高频报错的根因分析为什么“xxx is not a function”“Cannot read property of undefined”很多初学者看到Cannot read property length of undefined就慌了其实这类问题 90% 是对象结构里少了某一层。比如接口数据返回来你以为data.list是数组结果这次是data直接是null。解决方案是写访问保护比如data?.list?.length现代 JS 对这个问题有很成熟的解法。这背后还涉及一个思考“你到底应该信任哪个层级的结构是接口返回的还是框架 store 里的”我的经验是尽量在数据入口处就做数据清洗与合规化不要让undefined如幽灵般在代码里游走。另一种高频问题就是“对象中的方法报错不是函数”。这种多半是原型链出了问题。比如你用Object.create(null)创建对象然后又调用它上面的默认方法直接报错。或者你在继承中忘了重新指定constructor导致后续instanceof判断结果出错。这种排查没有捷径就是靠对原型链的熟悉程度。5.2 必坑速查表问题、原因、解法一页全看懂问题现象根本原因排查方向与解决对象修改影响了其他地方浅拷贝共享了嵌套引用地址深拷贝或按需拆结构for...in遍历出了意料之外的属性原型链上的可枚举属性混入用Object.keys或Reflect.ownKeysJSON.stringify输出为空对象undefined、函数、Symbol、循环引用用structuredClone或自定义判断方法里的this变成undefined丢失绑定或严格模式下默认绑定为undefined用bind、箭头函数捕获、或显式callObject.create(null)创建的对象toString不能用无原型对象天然缺少Object.prototype方法需要使用对象方法时不要用裸对象Object.keys拿不到 Symbol 键keys只返回字符串键用Reflect.ownKeys深拷贝处理循环引用报错递归互相引用导致栈溢出使用WeakMap记录已拷贝对象Object.freeze之后还是被改了冻结是浅层的嵌套对象依然可变需要递归冻结或使用代理深冻结Object.assign合并后结果不符合预期后面的属性覆盖了前面的或者浅拷贝导致嵌套属性冲突明确合并规则或使用深合并工具5.3 优化心法面向对象的性能提速与内存释放实际项目中如何用起来聊性能会首先想到 V8 下的隐藏类和对象内联缓存。不必死记但要有意识不要频繁增删对象属性因为这会破坏隐藏类的优化。举个实际案例团队之前有个循环频繁给对象动态添加一个status状态位结果在数据量大时明显比别人写法慢了 20% 以上。改成构造时就把所有属性字段初始化完整性能立刻回来了。内存释放也很重要。在大型单页应用中一个长期存在的全局对象会保留大量引用导致 old space 无法回收。我的建议是离开页面时手动将大对象置为null断开引用链。此外尽量不要用Object.prototype上挂方法一旦污染整个应用所有的对象循环遍历都会变慢。我可以分享一个我自己一直在用的习惯创建一个“数据清洗层”专门把接口返回的数据整理成规范的对象模型该默认值给默认值该嵌套的嵌套好之后再进入业务代码。这比让每一个组件都自己去判断字段是否存在要高效太多。对象模型的稳定是整个项目稳定的一半。个人回顾来讲我对对象理解最深的时刻不是看文档而是离线排查了一个因原型链污染导致全线组件报错的凌晨。那次之后我特别能把原型链、属性描述符、拷贝这些知识串到一起。对象其实是一块地基你越早把这里夯实之后不管写业务还是读框架都会顺得多。