做了这么多年前端，几乎每个项目里都离不开 ES6 的语法特性。解构赋值、箭头函数、Promise、Map、Set、class、模块化……这些特性早就成了日常开发的基本操作。但说实话，大部分同学对这些知识点的掌握是"零散"的：会用解构，却说不清默认值触发条件；用过 Map，却没对比过它和 Object 的性能差异；会写 async/await，遇到并发请求还是一团乱麻。这篇笔记不是把 ES6 语法逐条抄一遍，而是把我这些年实践下来觉得最值得深挖的知识点串成体系，讲清楚每个特性背后的设计意图、使用场景和真正容易踩的坑。适合已经能熟练写 ES6、但想系统梳理一遍的开发者，也适合准备面试、想查漏补缺的朋友。
1. 解构赋值：从"取值"到"析构"的思维转变
1.1 解构的本质是模式匹配，不是"取属性"
很多教程把解构赋值讲成"从对象里取属性的一种简便写法"，这其实低估了它的价值。解构赋值的底层逻辑是模式匹配：等号左边的结构，决定了从右边数据里提取哪些部分。这意味着它能处理的不只是普通对象，还有数组、嵌套对象、函数参数，甚至是返回值。
数组解构最经典的场景是交换变量：
let a = 1; let b = 2; [a, b] = [b, a]; // 不需要中间变量 temp这个写法能成立，是因为[b, a]先把右侧的值组成了一个新数组，再按位置匹配给a和b。它本质上是"先重组、再分配"两个步骤，理解这一点，就不会在复杂解构面前发怵了。
对象解构的匹配逻辑和数组不同，它靠的是属性名而非位置：
const user = { name: '张三', age: 30, address: { city: '北京' } }; const { name, age } = user;这里有个开发中非常实用但容易被忽略的点：解构出来的变量名，默认就是属性名。如果你想重命名，需要写{ name: userName }。很多人在需要重命名时傻傻地先解构再手动赋值，其实完全没必要。
函数参数的解构值得一提。当你封装一个接收配置对象的函数时，直接在参数位置解构，能让调用方和使用方都清晰很多：
function request({ url, method = 'GET', headers = {} }) { // url、method、headers 直接可用 } request({ url: '/api/user' });这样写的好处是：默认值在声明处就能看到，代码自注释性很强，不需要进函数体里翻到底才知道参数有哪些。
1.2 默认值的触发条件和嵌套解构的坑
解构的默认值有两个重要规则，我面试时经常问别人，能准确说清的不多。
规则一：只有属性值是undefined时，默认值才会生效。如果属性值是null，默认值会被无视，直接返回null。
const { name = '默认名' } = { name: null }; console.log(name); // 输出 null，而不是 '默认名'这个特性在实际中很容易埋雷。比如接口返回的数据里某个字段值为null，你以为默认值会兜底，结果渲染到页面上直接出现空白，排查半天才发现是解构默认值"不背这个锅"。
规则二：默认值可以是表达式，甚至可以引用同一次解构中其他变量，但要注意声明的顺序。比如{ width = 100, height = width * 2 }是合法的，但反过来写{ height = width * 2, width = 100 }就会报引用错误，因为width在height求值时还未完成绑定。
嵌套解构是另一个常见的"看着会、写着错"的点。当你处理多层嵌套数据时，每一层的括号都要写对：
const data = { items: [{ id: 1, info: { title: '标题' } }] }; const { items: [{ info: { title } }] } = data; console.log(title); // 标题这里的items: [...}不是数组索引的意思，而是"把 items 这一项解构成一个含单元素的数组，再继续往下取 info"。这种写法在应对复杂接口数据结构时非常省事，但建议只在数据格式非常稳定时使用。接口数据结构一旦变化，解构表达式会直接抛出难以定位的错误，这算是一把双刃剑。
实际开发中我推荐的做法是：解构用在边界清晰、结构稳定的地方（组件 props、常量配置、函数参数），而接口返回的深层数据，用解构前先做一层字段存在性校验，或者配合可选链?.使用。比如const { user = {} } = res; const { list = [] } = user;的分层级解构，比一次到底更稳妥。
2. 深拷贝：手写实现里的 ES6 新特性
2.1 先搞清楚浅拷贝和深拷贝的分界线
"es6 深拷贝"是前端社区的高频搜索词，说明这个看似基础的话题，实际生产中坑最多。浅拷贝只复制对象的第一层结构，深层的引用关系仍然共享；深拷贝要求生成一个完全独立的副本，任何一层的数据变化互不影响。
const original = { a: 1, nested: { b: 2 } }; const shallow = { ...original }; shallow.nested.b = 999; console.log(original.nested.b); // 999，浅拷贝共享深层引用 const deep = JSON.parse(JSON.stringify(original)); deep.nested.b = 888; console.log(original.nested.b); // 999，深拷贝互不影响展开运算符...是 ES6 里最常见的浅拷贝工具，它比Object.assign写得简洁，但本质是一回事。如果你没意识到它只处理了第一层，共享引用的问题就会在不知不觉中渗透到项目各处。
2.2 两种"省事"深拷贝方案的真实限制
生产环境里最常见的深拷贝方案是JSON.parse(JSON.stringify(obj))，这个方案我有太多话想说。它的优点是绝对简洁、一行搞定，但缺点同样明显：undefined、function、symbol 会被直接丢弃，Date会被转成字符串，RegExp、Map、Set会变成空对象，循环引用直接抛错。
const obj = { date: new Date(), fn: () => {}, symbol: Symbol('test'), map: new Map([[1, 2]]), un: undefined }; console.log(JSON.parse(JSON.stringify(obj))); // 输出：{ date: '...字符串...', map: {} } 其余字段全部丢失对很多后端返回的纯数据对象来说，这个方案还能凑合。但一旦对象里有Map或Date，结果就会变得非常不可控。另一个现实问题是当对象存在循环引用时，这个方案直接抛出Converting circular structure to JSON异常。
ES2021 带来了structuredClone()，这是浏览器原生支持的深拷贝 API，能正确处理Map、Set、Date、ArrayBuffer等绝大多数结构化类型，也能处理循环引用。但它有两个限制：一是不能拷贝函数和Symbol值，如果对象里有这些内容会直接抛错；二是浏览器兼容性逐年变好，但某些低版本运行环境仍然不支持。我目前的做法是优先考虑structuredClone，当对象确定只含纯数据时用它最省心，涉及函数或特殊类型再退回手写递归。
2.3 手写深拷贝的完整方案与循环引用处理
手写深拷贝是我建议每个前端至少完整实现一次的练习，因为它能让你彻底理解对象系统。一个健壮的深拷贝函数需要考虑这些分支：
function deepClone(source, hash = new WeakMap()) { // 基本类型和函数直接返回，函数不需要拷副本 if (source === null || typeof source !== 'object') { return source; } // Date 和 RegExp 有各自特殊的内部槽位，需要针对性处理 if (source instanceof Date) { return new Date(source.getTime()); } if (source instanceof RegExp) { return new RegExp(source.source, source.flags); } // 循环引用检测：如果已经拷贝过这个对象，直接返回已有副本 if (hash.has(source)) { return hash.get(source); } // 用 Object.create(Object.getPrototypeOf(source)) 可以保留原型链 const target = Array.isArray(source) ? [] : Object.create(Object.getPrototypeOf(source)); hash.set(source, target); // Map 和 Set 需要单独处理内部迭代器 if (source instanceof Map) { source.forEach((value, key) => { target.set(deepClone(key, hash), deepClone(value, hash)); }); return target; } if (source instanceof Set) { source.forEach((value) => { target.add(deepClone(value, hash)); }); return target; } // Reflect.ownKeys 能拿到包括 Symbol 在内的所有自身键，比 Object.keys 更完整 Reflect.ownKeys(source).forEach((key) => { target[key] = deepClone(source[key], hash); }); return target; }这段代码里最关键的设计是hash参数。它用 WeakMap 记录"源对象到副本"的映射关系，当遇到循环引用时直接返回已有的副本，而不是无限递归。为什么选WeakMap？因为它的键是弱引用，不会阻止原对象被垃圾回收，避免拷贝过程本身造成内存泄漏。这是一个非常体现 ES6 新数据结构价值的场景。
实际使用中还有一个取舍问题：是否拷贝函数。严格来说，深拷贝函数没有意义——函数通过闭包持有外部状态，你没法真正"拷贝"一份独立的闭包。大多数实现都选择原样返回函数引用。如果你确实需要序列化函数，那只能走字符串转换再 eval 的老路，但那是极不推荐的脏操作。我的经验是，拷贝函数时直接返回原引用，并在代码注释里写清楚这个决策，后续维护的人就不会误以为这是漏写了。
手写版还有一些可以聊的细节。比如对象原型链的处理，Object.create(Object.getPrototypeOf(source))能保留原型，但如果你只是处理纯 JSON 数据，直接{}也没问题，还能避免意外触发原型上的 getter 执行。再比如属性描述符的保留，上面简写版使用赋值方式复制属性，会丢失readonly、enumerable: false等元信息；严格做深拷贝可以用Object.defineProperties配合Object.getOwnPropertyDescriptors来实现，但大多数业务场景不需要这么底层。深拷贝的正确度取决于应用场景，这是我想强调的一点，不存在一个万能完美实现，按需裁剪才是正解。
3. Map 与 Set：更合适的数据结构选择
3.1 Map 和 Object 的差异比想象中大得多
Map是 ES6 引入的真正的哈希表实现，很多用它只是为了"不报错"，但从没认真对比过它和Object的本质差异。两者最大的区别在键的类型：Object的键只能是字符串或Symbol，而Map的键可以是任意值，包括对象、函数、NaN。
const map = new Map(); map.set('key', 'value'); map.set({ a: 1 }, 'objectKey'); // 对象作为键 map.set(NaN, 'NaNKey'); // NaN 也能作为键，且内部通过 SameValueZero 可正常命中这里有个冷门考点：NaN === NaN在 JS 中是false，但Map内部用的是SameValueZero算法，所以map.get(NaN)能取到值。如果换成普通对象，你只能用字符串拼接类的技巧绕路。
迭代方式是另一个明显的分水岭。Map本身就是可迭代对象，for...of直接遍历entries；而普通对象只能用for...in或Object.keys/values/entries转换，for...in还会遍历到原型链上可枚举的属性，需要额外用hasOwnProperty过滤。遍历顺序也有讲究，Object的键顺序有特殊规则（整数键会优先升序排列），Map则严格按插入顺序排列，这让Map在需要顺序保证的场景里更可靠。
增删查的性能是选择Map的另一个理由。频繁对对象进行动态增删属性时，V8 做的隐藏类和字典模式切换可能带来性能损耗，而Map作为专用哈希结构，插入和删除的性能更稳定。如果你有一段代码需要高频执行obj[key] = value和delete obj[key]，建议直接用Map。
日常开发最常见的直觉误区是"接口返回的对象结构我都熟悉，直接用对象不香吗"。我的看法是：静态结构用对象，动态读写用 Map。所谓静态结构，是字段数量固定、访问模式明确的数据，比如用户信息、配置项；动态读写的场景则包括缓存表、字典表、关联映射。判断标准很简单：你需不需要"遍历所有键"来配和其他逻辑？需不需要非字符串类型做键？需不需要频繁删除键？命中任意一条，就切换到Map。
3.2 WeakMap 的隐藏价值：私有变量与对象附加状态
WeakMap是Map的弱引用版本，键只能是对象，并且不阻止键对象被垃圾回收。这个特性让它在两类场景里特别有用：一类是给外部对象挂载额外状态而不污染原对象；另一类是配合深拷贝解决循环引用，上文已经用过。
先看对象附加状态的场景。假设你有一批第三方库返回的对象，你想给每个对象记录"是否已处理"的标记，但不想直接改动这些对象的结构，用WeakMap就是干净的做法：
const processed = new WeakMap(); function markAsProcessed(item) { processed.set(item, true); } function isProcessed(item) { return processed.has(item); }使用普通Map在这里有个隐患：如果item被业务回收，Map里的键依然强引用着它，导致内存无法释放。WeakMap的弱引用特性让键对象被回收后，对应的记录也自动失效，这是它被创造出来的根本原因。
WeakMap还常被用来实现类的私有变量。在原生#私有字段还不好用的年代，很多库就是用WeakMap保存实例内部状态的。把私有数据存在 WeakMap 里，键是实例对象，外部无论怎样都拿不到这个 WeakMap 的内容，比起约定俗成的_value下划线命名，安全性高得多。
要注意WeakMap没有size属性，也没有keys()、values()、entries()这些遍历方法，这和它的设计初衷有关——因为键是弱势引用，遍历行为无法保证结果完整，所以 API 直接砍掉了遍历能力。面试时如果你想装得老练一些，可以说出这一点，会显得你对它理解得比较透。
3.3 Set 的去重能力与数组互转
Set的核心特点是成员唯一性，它用SameValueZero算法判断重复，与Map的键比较逻辑一致。数组去重是Set最经典的应用：
const arr = [1, 2, 2, 3, 4, 4, 5]; const unique = [...new Set(arr)]; console.log(unique); // [1, 2, 3, 4, 5]这里利用了数组展开运算符...和Set的可迭代性，一行完成去重。注意到NaN在数组去重场景下有个细节：[...new Set([NaN, NaN])]得到[NaN]，它按 SameValueZero 比较，所以NaN也能被正确去重。而如果你用indexOf写去重，NaN永远匹配不到，老代码通常会留下这个 bug。
Set转数组有两种等价写法：Array.from(set)和[...set]。前者语义是"从类数组或可迭代对象生成数组"，后者是展开语法，两者都能用。性能上差距不大，我习惯用Array.from，因为它是标准 API，从命名上能看出意图。
Set还提供add、delete、has、clear等方法，其中has在查找效率上比数组的includes或indexOf更有优势，因为Set内部是哈希结构，时间复杂度平均为 O(1)，而数组线性查找是 O(n)。当你需要高频判断"某个元素是否存在"时，用Set维护一个白名单集合，比在数组里一遍遍遍历高效得多。我经常拿Set做前端权限判断、已加载模块记录这类"成员集合"型数据。还要记住一个重要差异：Set存的成员是有序的，按插入顺序迭代，所以如果你把数组丢进Set再去重，顺序不会乱，这一点日常够用了。
4. 异步进化：Promise 与 async/await 的正确打开方式
4.1 Promise 的状态机制和微任务秩序
Promise彻底改变了 JavaScript 的异步编程方式。它的核心是状态机：每个 Promise 有pending（进行中）、fulfilled（已成功）、rejected（已失败）三种状态，状态一旦从pending迁移，就不可再变。这个"不可逆"特性保证了.then()里的回调最多执行一次。
const p = new Promise((resolve, reject) => { setTimeout(() => resolve('成功'), 1000); // 后面再调用 reject 无效，状态已锁定 });then方法返回的也是 Promise，这正是链式调用的基础。每次链式调用会进入微任务队列，微任务优先于宏任务（setTimeout、setInterval）执行。这个顺序在工程上有实际意义，比如你await一个 Promise 后紧接着修改 DOM，DOM 更新会在微任务阶段完成，不会等到下一次宏任务循环。
如何看待链式调用里的return和throw？在then回调里return一个值，会把它包装成新的 Promise 继续往下传；throw一个错误，则会把链条状态切换成rejected，跳到最近的catch。很多人写代码时，在then里直接操作外部变量而不通过return传递，这会导致链条之间数据耦合度高、调试困难。我常用的风格是：把每一步想成"输入、处理、输出"，上一个阶段的输出通过return传给下一个阶段，链条天然形成了数据处理流水线。
4.2 async/await 让异步代码长成了同步的样子
async/await是Promise的语法糖，但用好了真的能让复杂异步逻辑的可读性提升一个档次。async函数总会返回一个Promise，即使你写async function() { return 1; }，调用方拿到的也是一个已决议的 Promise。await会暂停async函数执行，等 Promise 决议后再继续往下走——暂停的代价是函数整体被包成一个的 Promise 放进微任务队列，不会真正阻塞主线程。
async function loadUserData(userId) { const user = await fetch(`/api/user/${userId}`).then(res => res.json()); const posts = await fetch(`/api/user/${userId}/posts`).then(res => res.json()); return { user, posts }; }这段代码简单但顺序执行，两次网络请求会串行。如果两次请求没有依赖关系，用Promise.all并发执行会更高效：
async function loadUserData(userId) { const [user, posts] = await Promise.all([ fetch(`/api/user/${userId}`).then(res => res.json()), fetch(`/api/user/${userId}/posts`).then(res => res.json()) ]); return { user, posts }; }Promise.all接收可迭代的 Promise 集合，等全部成功才返回结果数组；只要有一个失败，整体直接进入rejected。它适合"多个请求全部成功后统一处理"的场景。相对地，Promise.allSettled等待所有 Promise 都结束（无论成功失败），返回每个 Promise 的状态和值，适合批量提交后逐个分析结果的场景。而Promise.race谁先完成就用谁的结果，常用于超时控制：
async function fetchWithTimeout(url, timeout = 5000) { const controller = new AbortController(); const timer = setTimeout(() => controller.abort(), timeout); try { const response = await fetch(url, { signal: controller.signal }); return await response.json(); } finally { clearTimeout(timer); } }这里用AbortController配合Promise.race的思路实现了超时中断，注意把清理定时器的逻辑放进finally，避免定时器泄漏。实际开发中，"串行依赖"和"并发无依赖"是两种最基础的接口编排模式，建议一看到连续的await，就先想想能不能改成并行。
4.3 错误处理的第一原则：async 里别裸 try/catch
async/await的错误处理写法直接影响代码质量。很多新人喜欢把大段逻辑包进try/catch，catch 之后打印一句错误然后继续，这很糟糕——错误其实被吞了。更好的思路是分层处理：在真正需要恢复的边界处理错误，不要每一层都接住它。
一个实用的模式是把网络请求的错误处理封装成返回元组，像 Go 风格一样：
async function safeRequest(fn) { try { const data = await fn(); return [null, data]; } catch (error) { return [error, null]; } } const [error, data] = await safeRequest(() => fetch('/api/user').then(r => r.json())); if (error) { // 在这里处理错误 UI 或重试逻辑 }这种写法把"成功/失败"变成显式可解构的结果，避免到处写try/catch，对齐语义也更清晰。还有一种选择是在调用链尾部统一.catch，适合"失败不影响主流程，但要上报"的场景。
关于 Promise 的错误有一个关键注意点：Promise 的异常不会自动被try/catch捕获，必须用异步方式接住。如果你不调用.catch也不await，rejected的 Promise 会在控制台上报一个未处理的 Promise rejection，严重时甚至导致进程退出。Node.js 环境下尤其如此，名单里的unhandledRejection事件一多，就是代码里存在没人接的 Promise 的最佳证明。
5. class 与 ES Module：工程化时代的组织武器
5.1 class 的语法糖本质与私有字段的取舍
class是 ES6 引入的语法，本质是 构造函数 + 原型链 的封装。它不是一个新的面向对象模型，而是让原型继承的写法更接近主流语言的类的形态。过去用构造函数写继承，prototype相关代码繁琐易错，class把constructor、extends、super都变成了声明式语法：
class Animal { constructor(name) { this.name = name; } speak() { return `${this.name} 发出声音`; } static create(name) { return new this(name); } } class Dog extends Animal { constructor(name) { super(name); // 调父类构造器，必须在访问 this 之前 this.type = '狗'; } speak() { return `${super.speak()}，汪汪`; } }super的用法里有一个高频出错点：在子类构造函数中，必须先调用super()才能使用this。这是因为 ES6 的 class 派生类在super()之前处于"未初始化"状态，这是语言层面的规定，不是风格问题。另外super在方法里调用会保持this绑定，这点和 Java 里的super.method()很不同。
ES2021 引入了原生私有字段#语法，它和传统下划线约定_field的最大区别是：真正从语言层面保证了无法从外部访问。我平时用#的频度不高，只在封装内部状态不希望外部窥探时用。它有一个好处是避免命名冲突，因为私有名的定义是"类内可见的 Slot"，不同类里同名的#value互不干扰。
关于 class 的推荐程度，我觉得需要看场景。纯数据模型或工具函数集合其实用普通对象/纯函数更合适，class 的核心价值在"必须携带状态而且有复杂的行为依赖关系"的对象。如果只是几个方法挂在一个数据上，箭头函数加闭包同样能解决问题，不必强行上类。
5.2 模块的几种导出形式和循环依赖的雷区
ES Module（ESM）是 ES6 最有工程意义的特性之一。import/export让代码的组织方式从"全局变量挂载"进化成了显式依赖图。常用导出形式我整理成一张速查表：
| 导出方式 | 写法 | 导入方式 |
|---|---|---|
| 默认导出 | export default function() {} | import fn from './module' |
| 具名导出 | export const a = 1; export const b = 2; | import { a, b } from './module' |
| 混合导出 | export default fn; export const helper = ...; | import fn, { helper } from './module' |
| 重导出 | export * from './base'; | 汇总入口常用 |
| 运行时加载 | import('./module').then(m => m.default); | 动态 import，按需加载 |
默认导出和具名导出的选择长期有争议。我的原则是：如果一个模块只有一个核心出口，用默认导出；如果模块是一个命名空间，提供多个函数，全部用具名导出。单一出口的库（比如某个组件的入口）默认导出更自然；工具函数集合全部具名，IDE 自动补全和 tree-shaking 的效果都更好。具名导出还有一个优势：导入时写错名字会立刻报错，而默认导出导入方可以随意改名，容易在项目里造成同名不同义的问题。
循环依赖是模块化开发里最隐蔽的雷区。A 导入 B，B 又导入 A，ESM 是静态分析、编译时确定导入导出的，所以循环依赖不一定立刻报错，但会带来变量提升和初始化顺序的问题。典型的场景是 B 模块在初始化阶段读取 A 导出的值，而 A 模块此时尚未执行完毕，导出值是undefined。排查这类 bug 的经验是：在触发循环引用的模块里打点输出导出值的读取时机，再配合import()动态加载打破循环。ESM 的设计其实比 CommonJS 更容易发现循环依赖问题，因为它有静态分析提示，但很多构建工具会将其降级处理，所以不要依赖"没报错就是安全"。
动态import()是我最喜欢的模块特性之一。它把模块加载从"编译期"推后到了"运行期"，可以用在按需加载路由组件、懒加载大型图表库等场景。配合React.lazy或Vue的异步组件，它能显著优化首屏体积。要注意的是，动态 import 返回 Promise，模块导出内容在.then里取，结构变化不会影响它的本质。
6. 高频问题与排查速查表
6.1 我经常踩的 ES6 坑集合
下面这组问题是我在代码评审和日常排错中最常遇到的 ES6 相关场景。有些看起来是语法失误，实际上是概念没有内化。
| 问题描述 | 错误示例 | 正确姿势 | 说明 |
|---|---|---|---|
| 解构默认值不生效 | const { name } = {name: null}期望默认名 | 使用const { name = '默认' }时先确保字段是undefined而非null | 空值回退要区分null和undefined |
Set去重误以为对象也去重 | new Set([{a:1}, {a:1}]).size === 2 | 对象比较的是引用，不是结构 | 需要按内容去重先序列化或建 key |
Promise.all失败整体挂掉 | 批量请求中个体失败就没法拿到其他成功结果 | 改用Promise.allSettled | 全部完成的语义与全部成功的语义不同 |
for...of直接遍历对象报错 | for (const k of {a:1}) | 先Object.entries()转数组或用for...in | 普通对象不是可迭代对象 |
Object.keys漏掉 symbol 键 | Object.keys({ [Symbol('s')]: 1 })返回空数组 | 需要 symbol 键时用Reflect.ownKeys() | Reflect.ownKeys返回包括字符串与 symbol 的全部自身键 |
箭头函数不能用arguments | 在箭头函数里访问arguments拿到外层函数的arguments | 需要参数列表时用rest参数...args | 箭头函数没有自己的arguments绑定 |
Map键是对象时误以为按内容匹配 | map.get({a:1})取不到map.set({a:1}, 'x')存入的内容 | 对象键按引用匹配，需要内容匹配则给对象创建稳定引用或改用字符串键 | 哈希表键语义是引用相等 |
这些坑的共性是：很多 ES6 特性是从语言层面重新设计了语义，不能拿以前 object/array 的惯性去猜。
6.2 排查思路：从语法错误到运行时数据的定位顺序
当你的 ES6 代码运行异常，我建议按下面的顺序排查，能少走弯路。
第一步先看语法层。如果你用了私有字段#或可选链?.，确认运行环境（浏览器版本、Node 版本）和构建工具的 transpile 配置是否支持。这类报错往往出现在开发者本机正常、测试环境挂掉的情况，多半是目标环境差异导致的。别急着调业务逻辑，先确认语法有没有被正确降级。
第二步看数据类型。ES6 的数据结构各有各的规矩，Map的键是引用比较，Set的成员唯一也基于引用比较，WeakMap的键只能是对象。运行时报Invalid value used as weak map key、报Set的size不如预期时，先怀疑是不是把原始值丢给了要求对象作为键的位置。这时在关键节点console.log数据结构和它的类型，比瞎改代码快得多。
第三步看异步时序。await并不会让所有代码等在那里，微任务和宏任务的交错经常导致"明明数据返回了，页面却没更新"或"多个请求触发顺序不符合预期"的情况。遇到这类问题，把关键异步节点的日志时间戳打印出来，对照事件循环顺序，很快能定位是不是某个 Promise 的时序比预期晚或比预期早。前面说的Promise.all和Promise.allSettled混用，也是这步最容易发现的。
最后分享一个我执行多年的习惯：在标签页被激活时，我通常会在devtools里把相关 Promise 标记为log并启用异步栈追踪。现代浏览器的异步栈对async/await的支持已经很好，能直接展示 await 调用链，排查 Promise 内部渐近式 bug 时比盲打console.log高效很多。
7. 后记
这些年看过的 ES6 代码少说也有几十万行，我的感受是：ES6 最牛的地方不在于单个语法多酷炫，而在于它让 JavaScript 的工程化水平整体上了一个台阶。解构帮你避开数据深层访问的危险，Map 和 Set 补齐了数据结构的短板，Promise 和 async/await 驯服了回调地狱，模块化让代码边界变得清晰可查。你不需要每一条特性都背得滚瓜烂熟，但理解每一种特性背后想要解决的问题，比记住语法本身重要得多。如果你刚开始系统整理 ES6，我的建议是从手写深拷贝和 Promise 并发控制开始练手，这两个问题能把你对对象、引用、异步的理解全部串起来。遇到坑别慌，把本篇的排查顺序捋一遍，八成能解决。
