ECMAScript 2026 深度拆解：第 17 版规范正式落地——7 大新特性如何重塑 JavaScript 的工程实践

2026 年 6 月 30 日，ECMA International 正式批准 ECMAScript 2026（ECMA-262 第 17 版）。这一版没有惊天动地的语法糖，却一次性补齐了 JavaScript 标准库里最"硌脚"的 7 块短板。本文从工程师视角，逐个拆解这些特性背后的算法、痛点与实战代码，并给出可落地的迁移策略。

一、背景：ES2026 到底"新"在哪

先说清楚一个常见的误解：ECMAScript 每年一个大版本，这个版本就是当年进入 Stage 4 的全部提案的集合，而不是某个神秘委员会拍脑袋想出来的"新语言"。TC39 的流程是 Stage 0（草稿）→ Stage 1（方向）→ Stage 2（草案）→ Stage 3（候选）→ Stage 4（ finished，即被正式接纳）。只有走到 Stage 4 的提案，才会随当年 6 月的版本号一起冻结落地。

这意味着看待 ES2026 的正确姿势，不是"我又得学一堆新语法"，而是"今年有哪些长期靠三方库硬撑的能力，终于被官方收编了"。

这里有一个关键分野要分清：

• 语法特性（新关键字、新表达式）：通常需要 Babel / SWC 编译才能跑在低版本引擎上，有"转移成本"。
• 标准库 API（给 Math、Array、Map、Uint8Array、JSON 等对象加新方法）：纯运行时能力，引擎原生实现，零编译成本，只是需要引擎版本够新。

ES2026 的全部 7 个特性，清一色是标准库 API，不涉及任何新语法。这对工程团队是巨大利好：你不用动构建链，只要运行时（浏览器 / Node / Deno / Bun）够新，就能直接用。

⚠️ 辟谣时间：网上有不少文章把 Temporal（日期时间终极方案）、Pipeline 运算符（|>）、Record & Tuple（不可变数据结构）写进"ES2026 特性"。截至 2026 年 6 月 30 日获批版本，这些提案都还没进 Stage 4，不在本次规范里。它们仍在 Stage 2/3 的路上。本文只讲真实落地的特性，不画饼。

二、核心概念速览：7 大特性一张表

在逐个深挖之前，先建立全局认知。下面这张表是 ES2026 的全部新增能力，以及它们各自要解决的"旧痛点"：

可以看到一个清晰的工程信号：ES2026 的方向是"实用主义收编"——把社区里反复手写的、或被迫引入三方库的场景，做成零依赖的原语。下面我们逐个拆。

三、逐个深度拆解 + 代码实战

3.1 Math.sumPrecise()：终于能和浮点误差说再见

问题从哪来：IEEE 754 的"原罪"

每个 JS 工程师都踩过这个坑：

console.log(0.1 + 0.2);        // 0.30000000000000004
console.log(0.1 + 0.2 === 0.3); // false

原因是 JavaScript 的 Number 是 IEEE 754 双精度浮点数，二进制无法精确表示 0.1 和 0.2。这还不算最糟——最糟的是灾难性抵消（catastrophic cancellation）：

// 一个经典的反例：在大数旁边加一堆小数
const big = 1e16;
const smalls = Array.from({ length: 10000 }, () => 1);
const total = smalls.reduce((a, b) => a + b, big);
console.log(total);            // 10000000000010000  ← 误差！应该是 10000000010000
console.log(total - big);      // 10000 才对，但结果可能是 0 或被吞掉

当 big 的尾数精度远大于 smalls 的增量时，加法直接把小增量"吃"掉了。在金融对账、科学累计、统计聚合里，这种误差会悄悄放大成严重 bug。

算法真相：不是魔法，是补偿求和

Math.sumPrecise() 内部采用的正是经典的 Neumaier 补偿求和（compensated summation） 思想的精确变体——用一个额外的"补偿项"记录每次加法丢失的低位，下一轮把它加回来：

// 这是 Math.sumPrecise 的等价参考实现（Neumaier 算法）
function sumPrecise(iterable) {
  let sum = 0;
  let c = 0; // compensation：补偿被舍入吃掉的低位
  for (const value of iterable) {
    const y = value - c;
    const t = sum + y;
    c = t - sum - y; // 记录本次加法损失的部分
    sum = t;
  }
  return sum;
}

console.log(sumPrecise([1e16, ...Array(10000).fill(1)]) - 1e16); // 10000 ✓

原生实现会用引擎内更宽的累加精度（甚至借助整数/大数路径）把误差压到最低，行为比上面的 JS 参考实现更严谨。但它不是任意精度算术——结果仍是 Number（双精度），只是把"加法顺序导致的可避免误差"消掉了。如果你需要真正的小数定点运算，还是要上 BigInt 或 decimal.js。

实战：金融对账累计

// 场景：把一批带小数的交易金额累加成总额
const transactions = [
  128.45, 0.01, 99.99, 1234.56, 0.005,
  -50.0, 0.1, 0.2,
];

// 旧写法：朴素 reduce，金额跨度大时可能有尾差
const naive = transactions.reduce((a, b) => a + b, 0);

// ES2026 写法：语义清晰 + 精度更稳
const precise = Math.sumPrecise(transactions);

console.log(naive);   // 1513.3150000000001（尾差）
console.log(precise); // 1513.315

边界坑

• 只对 Number 有效：传入 BigInt 或非数字会抛 TypeError 或得到 NaN，它不会帮你做类型转换。
• 不是 BigInt 的平替：需要精确小数（钱）的场景，业务层仍建议以"分"为单位的整数或 BigInt 存储，sumPrecise 适合"已经是浮点、但求和要稳"的场景。
• 性能：仍是 O(n)，和朴素 reduce 同阶，但因为避免了误差累积，在数值跨度大时正确性收益远大于开销。

3.2 Iterator.concat()：惰性拼接，告别全量展开

背景：迭代器助手（Iterator Helpers）的收尾

从 ES2024 起，迭代器有了自己的"方法链"——Iterator.from(x).map().filter().take().drop()...，返回的都是惰性迭代器，不立即展开成数组。ES2026 补齐了其中缺失的关键一环：Iterator.concat()，用于把多个迭代器/可迭代对象惰性拼接成一个。

为什么不用 [...a, ...b]？

// 旧写法：全量展开，先建两个数组再合并，O(n+m) 内存
const merged = [...iterA, ...iterB];

问题在于：如果 iterA 是无限迭代器（比如生成斐波那契），或者数据量上 G，全量展开直接爆内存。Iterator.concat 是惰性的——它只在你真正去 next() 时才从源里取一个：

// ES2026：惰性拼接，支持无限迭代器
function* fibonacci() {
  let a = 0, b = 1;
  while (true) { yield a; [a, b] = [b, a + b]; }
}

const head = [0, 1, 2];
const combined = Iterator.concat(head, fibonacci());

// 只取前 10 个，不会把无限序列展开
console.log([...combined.take(10)]);
// [0, 1, 2, 0, 1, 1, 2, 3, 5, 8]

注意 Iterator.concat 接收的是迭代器或可迭代对象，返回值本身也是一个 Iterator，所以你可以继续 .map() / .filter() / .take() 链式调用——整条管道零中间数组。

实战：分页流式拼接

// 把多个分页请求（每个返回 async/同步的可迭代）合并成一个惰性序列
function* page(size, offset) {
  // 假设从某数据源按页拉取
  for (let i = offset; i < offset + size; i++) yield { id: i };
}

const all = Iterator.concat(
  page(100, 0),
  page(100, 100),
  page(100, 200),
);

// 上层按需消费，底层页才按需加载
for (const item of all.take(250)) {
  process(item);
}

最小 ponyfill（仅同步、惰性版）

function iteratorConcat(...iterables) {
  return (function* () {
    for (const it of iterables) {
      yield* it; // 惰性转发，不展开成数组
    }
  })();
}
// 用法一致：for (const x of iteratorConcat(a, b)) {}

原生 Iterator.concat 额外保证：拼接的是真正的迭代器对象（可继续调用迭代器助手方法），且对"非可迭代"入参会抛错，行为更严格。

3.3 Array.fromAsync()：异步源一站转数组

痛点：异步迭代只能用 for await...of 手搓

ES2026 之前，Array.from() 只能吃同步可迭代对象。遇到异步可迭代对象（async function* 生成的、或 ReadableStream 适配后的、或数据库游标），你只能手写循环：

// 旧写法：手搓
async function collect(asyncIterable) {
  const result = [];
  for await (const item of asyncIterable) {
    result.push(item);
  }
  return result;
}

ES2026 写法

// 签名：Array.fromAsync(asyncIterable, mapFn?, thisArg?)
const items = await Array.fromAsync(asyncIterableSource);

// 带映射函数，等价于 Array.from 的第二个参数
const ids = await Array.fromAsync(cursor, (row) => row.id);

实战：把 async generator 收束为数组

async function* fetchPages(urls) {
  for (const url of urls) {
    const res = await fetch(url);
    yield await res.json();
  }
}

// 一次性把所有页收进数组
const allData = await Array.fromAsync(fetchPages([
  '/api/p1', '/api/p2', '/api/p3',
]));

// 带 mapFn：边收边转换
const titles = await Array.fromAsync(fetchPages(urls), (doc) => doc.title);

边界坑

• 内存是全量的：Array.fromAsync 会把整个异步序列收进内存，本质和 for await 收集一样。超大数据流请改用惰性消费，别图方便一股脑转数组。
• 可取消性弱：一旦开始，没法像流那样 break 后自动通知上游停止（除非上游 async generator 自己监听 AbortSignal）。需要取消请用带信号的 ReadableStream 方案。
• 和 Array.from 非同名：它是 Array.fromAsync（静态异步方法），不是 Array.prototype 上的实例方法。

3.4 Error.isError()：跨 realm 判定错误的标准答案

旧方案的致命缺陷

过去判断"这是不是一个错误对象"，最常见两种写法，都有坑：

// 写法 A：instanceof —— 跨 realm 直接失效
try {
  constiframeError = window.frames[0].eval('new Error("x")');
  console.log(iframeError instanceof Error); // false！因为是另一个全局的 Error
} catch {}

// 写法 B：鸭子类型 —— 太容易被伪造
function isErrorLike(e) {
  return e && typeof e.message === 'string' && typeof e.stack === 'string';
}
isErrorLike({ message: 'fake', stack: 'fake' }); // true（假阳性）

在 iframe、Web Worker、vm 模块、不同 JS 运行时（Node 里的 vm.runInNewContext）之间传递错误时，instanceof 因为构造函数来自不同全局对象而失败；鸭子类型则太宽松。

ES2026 的 Error.isError()

Error.isError(new Error());            // true
Error.isError(new TypeError());        // true（识别原生错误子类）
Error.isError(new AggregateError([], 'msg')); // true
Error.isError(new DOMException());     // true（规范要求的原生错误）
Error.isError({ message: 'x' });       // false（拒绝伪造）
Error.isError('not an error');         // false

它基于**引擎内部的错误内在标记（intrinsic error tag）**判定，天然跨 realm——不管错误来自哪个全局环境，只要它是规范认可的原生错误，都返回 true。

实战：统一错误处理中间件

async function safeHandler(fn) {
  try {
    return await fn();
  } catch (err) {
    // 用 Error.isError 区分"真错误"和"被 throw 的普通值"
    if (Error.isError(err)) {
      logger.error(err.stack);
      return { ok: false, code: 'INTERNAL', message: err.message };
    }
    // 业务层 throw 的普通值（如 throw 'rate_limited'）
    return { ok: false, code: 'BIZ', message: String(err) };
  }
}

最小 ponyfill（利用内在 tag，跨 realm 安全）

function isError(value) {
  // 优先用 toString 内在 tag：跨 realm 也稳
  return (
    Object.prototype.toString.call(value) === '[object Error]' ||
    (typeof value === 'object' && value !== null && typeof value.stack === 'string')
  );
}

注意 ponyfill 对 DOMException、AggregateError 的覆盖不如原生全，生产环境还是优先用引擎原生实现 + 特性检测。

3.5 Map.getOrInsert() / getOrInsertComputed()：原子"查无则插"

旧写法的尴尬

"查不到就塞一个默认值"是高频操作，但旧写法有两宗罪：

// 写法 1：两步法，非原子，且读两次
if (!map.has(key)) map.set(key, defaultValue);
const v = map.get(key);

// 写法 2：链式 Hack，但 WeakMap.set 返回的是 WeakMap 本身，不是值！
const v = map.get(key) ?? map.set(key, computeDefault()).get(key);
//                              ↑ 对 WeakMap 这招没用，因为 set 不返回你刚塞的值

WeakMap 尤其惨：它的 set 返回 WeakMap 实例，没法链式 .get() 拿回刚插入的值，只能再 get 一次。

ES2026 写法

// 存在就返回现有值；不存在就插入 value 并返回它
const v = map.getOrInsert(key, defaultValue);

// 惰性版：只有 key 缺失时才调用 compute(key)，避免无谓计算
const expensive = map.getOrInsertComputed(key, (k) => heavyCompute(k));

getOrInsertComputed 的回调是惰性的——key 已存在时，回调根本不会执行。这在默认值计算昂贵（如解析、网络、加密）时至关重要。

实战 1：分组 / 计数 / 记忆化

// 把日志按级别分桶
const buckets = new Map();
for (const log of logs) {
  const arr = buckets.getOrInsert(log.level, []);
  arr.push(log);
}

// 记忆化斐波那契（惰性默认）
const memo = new Map();
function fib(n) {
  return memo.getOrInsertComputed(n, (k) => {
    if (k < 2) return k;
    return fib(k - 1) + fib(k - 2);
  });
}

实战 2：WeakMap 存储私有元数据

const meta = new WeakMap();

function attachMeta(obj, factory) {
  // 以前 WeakMap 没法优雅地"查无则插"，现在可以了
  return meta.getOrInsertComputed(obj, () => factory(obj));
}

// 对象被 GC 时，meta 里的条目自动释放，无内存泄漏

边界坑

• getOrInsert 的 value 是立即求值的：即使 key 已存在，value 表达式也会先算出来再被丢弃。要惰性请用 getOrInsertComputed。
• 不是并发原子的：JS 单线程，但 await 点会让微任务交错。如果你在 getOrInsertComputed 的回调里做异步或重入 map，要自己保证回调的幂等性。
• 不要覆盖内置原型方法：别手贱 Map.prototype.getOrInsert = ...，用 ponyfill 函数更稳（见迁移章节）。

3.6 Uint8Array 编解码内建：浏览器终于不用 Buffer 了

痛点：浏览器没有 Buffer

在 Node 里处理 base64/hex 很爽：Buffer.from(str, 'base64')。但浏览器原生没有 Buffer，过去要么引三方库（如 base64-js），要么手写（容易写出 bug 且慢）。ES2026 把这个能力直接做进了 Uint8Array：

// 字符串 → base64 字符串
const bytes = new Uint8Array([72, 101, 108, 108, 111]); // "Hello"
bytes.toBase64();                 // "SGVsbG8="

// base64 → Uint8Array（静态方法）
Uint8Array.fromBase64("SGVsbG8="); // Uint8Array(5) [72,101,108,108,111]

// hex 互转
bytes.toHex();                    // "48656c6c6f"
Uint8Array.fromHex("48656c6c6f"); // Uint8Array(5) [72,101,108,108,111]

完整方法清单：

实战：解析 JWT 的 payload

function decodeJwtPayload(token) {
  const [, payloadB64] = token.split('.');
  // 用 url-safe base64（JWT 用 -_ 代替 +/）
  const bytes = Uint8Array.fromBase64(payloadB64, { alphabet: 'base64url' });
  const json = new TextDecoder().decode(bytes);
  return JSON.parse(json);
}

alphabet 选项支持 'base64'（标准）和 'base64url'（URL 安全，-/_），直接覆盖 JWT、文件名等场景，不用自己替换字符。

setFrom* 的零分配妙用

setFromBase64 不新建数组，而是写入已有的 Uint8Array，并返回写入了多少字节、剩多少未消费的字符——这对流式解码超大 base64 极有用：

const buf = new Uint8Array(16);
// 分多次喂入 base64 片段
let cursor = 0;
function feed(chunk) {
  const { bytesWritten, remainder } = buf.setFromBase64(chunk, {
    alphabet: 'base64',
    lastChunkHandling: 'loose', // 允许尾部不足 4 字符的残块
  });
  cursor += bytesWritten;
  if (remainder) processChunk(buf.subarray(0, cursor)); // 处理完整块
}

lastChunkHandling 选项控制对"不完整尾部"的处理：'strict'（报错）、'loose'（容错）、'stop-before-partial'（丢弃残块），非常适合网络分包场景。

性能真相

原生实现是引擎层 C++ 代码，直接走查表 + 批量位运算，比任何 JS polyfill 都快且零中间字符串分配；setFrom* 系列更是原地写入，避免反复 new Uint8Array。在没有 Buffer 的浏览器和边缘运行时（Worker / Deno / Bun）里，这是真正的"地基级"能力。

3.7 JSON.rawJSON() + reviver 第三参数：JSON 精细控制

痛点：JSON 序列化会"丢信息"

JSON.stringify 对 BigInt、undefined、Date、Map 等要么抛错、要么静默丢字段。更要命的是，你没法让某个值"原样"落进 JSON：

// 想塞一个已经是合法 JSON 片段的字符串，结果被转义成字符串
const sub = '{ "x": 1 }';
JSON.stringify({ data: sub });
// "{"data":"{ \"x\": 1 }"}"  ← sub 被当字符串转义了，不是嵌套对象

ES2026 的 JSON.rawJSON()

JSON.rawJSON(value) 把一个值标记为"原始 JSON 片段"——stringify 时原样输出，不转义、不包裹引号：

const raw = JSON.rawJSON('{ "x": 1, "y": 2 }');
JSON.stringify({ data: raw });
// "{"data":{ "x": 1, "y": 2 }}"  ← 完美嵌套，无转义

// 保留特殊精度数字（双精度无法精确表示的超长/超大小数）
JSON.stringify({ big: JSON.rawJSON('1e400') });
// "{"big":1e400}"

// 判断是否为 rawJSON 包装
JSON.isRawJSON(raw); // true

这对模板化输出、代理透传、构造超大 JSON非常有用：你可以把已格式好的子串直接"嵌入"最终 JSON，省去解析再序列化的来回开销。

reviver 的第三参数 context：看见原始文本

旧 JSON.parse(text, reviver) 的 reviver 只有 (key, value)。ES2026 多了第三个参数 context，其中 context.source 是该值对应的原始 JSON 文本片段：

const text = '{"a": 1, "b": "hello", "c": [1,2,3]}';
JSON.parse(text, (key, value, context) => {
  if (key === 'c') {
    console.log(context.source); // "[1,2,3]" —— 原始未解析前的文本
  }
  return value;
});

这让你可以做无损透传/重写：比如只改某个字段、其余保留原始文本格式（包括空白、数字精度），而不是重新序列化导致格式漂移。

实战：JSON 字段重写但不破坏其余格式

function redact(text, sensitiveKeys) {
  return JSON.stringify(
    JSON.parse(text, (key, value, ctx) => {
      if (sensitiveKeys.has(key)) {
        // 用 rawJSON 把脱敏后的值原样写回，保留结构
        return JSON.rawJSON('"***"');
      }
      return value;
    })
  );
}

边界坑

• rawJSON 只能作为 value 节点，不能用于对象的 key。
• rawJSON 里的字符串必须是语法合法的 JSON 片段，否则 stringify 会抛错——引擎不会帮你校验内容合法性。
• 它解决的是"嵌入已合法 JSON"，不是"绕过序列化规则"。想序列化 BigInt 等，仍需先转成原始 JSON 文本再包 rawJSON。

四、性能优化：原生 vs polyfill 的真相

很多文章喜欢给 ES2026 特性贴上"性能提升 X 倍"的标签，但作为工程师要明白：标准库 API 的性能优势，几乎全部来自"引擎原生实现 + 避免 JS 层额外分配"，而不是算法复杂度有本质变化。下面给几个可自己验证的基准框架，结论我给定性的，数字请你在自己环境跑。

4.1 Math.sumPrecise vs 朴素 reduce

两者都是 O(n)。sumPrecise 多了补偿项计算（几次额外加减），单次循环略重，但换来的是精度正确性。在数值跨度小的场景两者速度接近；在跨度大、易抵消的场景，sumPrecise 是唯一正确答案。

function bench(label, fn, data) {
  const t0 = performance.now();
  const r = fn(data);
  const t1 = performance.now();
  console.log(`${label}: ${t1 - t0}ms, result=${r}`);
}

const data = [1e16, ...Array.from({ length: 5_000_000 }, () => 1)];
bench('naive reduce', (d) => d.reduce((a, b) => a + b, 0), data);
bench('sumPrecise', (d) => Math.sumPrecise(d), data);

4.2 Uint8Array.toBase64 vs JS polyfill

原生走引擎内查表 + 批量位运算，且 setFromBase64 是零分配原地写入。JS polyfill 每轮都要创建中间字符串/数组，大数据量下差距会非常明显（通常是数量级的差异，但具体倍数取决于数据规模，请自行测量）。

4.3 getOrInsertComputed 的惰性红利

真正省钱的是 getOrInsertComputed 的惰性：key 已存在时回调零成本；而 getOrInsert(key, heavyCompute()) 即使不需要也会先算出 heavyCompute() 的结果再丢弃。所以在"默认值是昂贵计算"的场景，务必用 getOrInsertComputed——这不是微优化，是架构级省 CPU。

五、兼容性与迁移策略：怎么安全地用起来

5.1 特性检测优先

ES2026 的 API 是"渐进可用"的。以 Math.sumPrecise、Map.prototype.getOrInsert 为例，主流引擎从 2026 年初陆续实装（Baseline 2026 级别）。上线前务必做特性检测：

const hasES2026 = typeof Math.sumPrecise === 'function'
  && typeof Map.prototype.getOrInsert === 'function'
  && typeof Uint8Array.fromBase64 === 'function'
  && typeof JSON.rawJSON === 'function';

5.2 用 ponyfill，不要用 polyfill

polyfill = 直接覆盖内置原型（如 Map.prototype.getOrInsert = ...），风险高：可能和别的库冲突、破坏 for...in、被未来引擎行为覆盖。ponyfill = 写成独立函数，不碰全局，随用随引：

// ponyfill 版 getOrInsert（不污染原型）
export function getOrInsert(map, key, value) {
  if (map.has(key)) return map.get(key);
  map.set(key, value);
  return value;
}

// 生产代码
const v = (Map.prototype.getOrInsert
  ? map.getOrInsert(key, value)
  : getOrInsert(map, key, value));

sumPrecise 的 ponyfill 就是前文 3.1 的补偿求和实现；Iterator.concat 用 3.2 的 iteratorConcat；Error.isError 用 3.4 的 isError。把这些收进一个 es2026-ponyfill 小模块，新引擎走原生、老引擎走兜底，平滑过渡。

5.3 TypeScript 与构建链

• TypeScript：需要把 lib 升级到包含 ES2026 定义（如 "lib": ["ES2026", "DOM"] 或 "ESNext"），否则类型层会报"属性不存在"。@types/node 等也需同步到支持版本。
• Babel / SWC：这些都是运行时 API，不是语法，Babel 没法"编译"出它们——它只能保证你的 import/语法不变，真正的实现必须在运行时存在。所以别指望转译能解决兼容，运行时垫片（ponyfill）才是正解。
• Node / Deno / Bun：检查各自版本说明，Math.sumPrecise、各类 Uint8Array 编码方法、JSON 增强在 2026 年的版本中逐步默认开启。

5.4 渐进增强的落地建议

1. 在团队基础库里放一个 es2026.ts，集中导出"原生或 ponyfill"的封装。
2. 业务代码只 import 这个封装，不直接调原生，方便一处切换、全局生效。
3. 在 CI 里加一条"禁止直接 Map.prototype.getOrInsert"的 lint 规则（防手滑覆盖原型）。
4. 对必须支持老浏览器的页面，用 core-js 之类按需引入对应垫片，但优先用轻量 ponyfill 替代重垫片。

六、总结与展望：ES2026 给工程师的启示

回看 ECMAScript 2026 的 7 个特性，你会发现一条清晰的主线：这一版没有教你新语法，而是把社区里"每个人都手写过、或者被迫引三方库"的脏活累活，做成了零依赖、引擎级、行为严谨的标准原语。

这背后是 TC39 近年越来越明显的工程导向：

• 减少三方依赖：Uint8Array 编解码让浏览器端终于能甩掉 base64-js；Math.sumPrecise 让许多场景不必引 decimal.js 处理求和误差。
• 内存与性能意识：Iterator.concat、Array.fromAsync 都在强调"惰性"和"流式"，契合大数据、流处理、边缘计算的趋势。
• 健壮性优先：Error.isError 解决跨 realm 判定的老大难；getOrInsertComputed 把"原子默认值"做成原语，减少手写两步法的竞态隐患。
• JSON 精细控制：rawJSON 和 reviver 的 context，回应了"JSON 不只是存储格式，更是模板与传输协议"的现实需求。

展望未来，真正会改变写法的"大特性"还在路上：Temporal（彻底替代坑爹的 Date）、Records & Tuples（原生不可变数据）、Pipeline 运算符（函数式管道）、Decimal（原生十进制）、以及更多的 RegExp / 正则增强。它们一旦进 Stage 4，就会像今年的 7 个特性一样，悄悄抹平我们过去十年的某些" workaround "。

给工程师的一句话建议：框架会过时，标准库不会。 与其追逐每个新框架的 API 变化，不如把 ECMAScript 标准库吃透——地基稳了，上层的楼才盖得快、盖得稳。ES2026 的这批新特性，正是给地基又浇了一层钢筋混凝土。

参考资料：ECMA International 于 2026-06-30 正式批准 ECMAScript 2026（ECMA-262 第 17 版）；相关提案已进入 Stage 4 并被纳入本年度规范。建议以各 JS 引擎（V8 / SpiderMonkey / JavaScriptCore）的官方发布说明为准核对具体版本的可用性。