JavaScript 的标准化进程由 TC39 委员会推动，新特性从提案到正式纳入 ECMAScript 规范需要经历多个阶段。装饰器、Record 与 Tuple、Temporal、管道操作符等提案目前分别处于 Stage 2 和 Stage 3，它们已经通过 Babel、TypeScript 等工具进入开发者的视野。理解这些提案的设计动机与语法细节，有助于我们在项目中合理引入未来的语法，同时避免过早依赖尚未稳定的特性。

一、ECMAScript提案阶段：如何判断一个特性是否可用

TC39 将每个新特性划分为五个阶段：Stage 0 表示想法雏形，Stage 1 表示正式提案，Stage 2 进入草案，Stage 3 表示候选推荐，Stage 4 则意味着已完成测试并纳入下一版规范。对于日常项目来说，Stage 3 是一个关键分水岭：此时语法基本稳定，但仍可能存在小幅调整，主流转译器会提供实验性支持；Stage 4 的特性则基本可以放心使用。

判断一个提案是否值得引入，除了看阶段之外，还要关注社区实现情况。例如当前装饰器提案处于 Stage 3，但 Babel 和 TypeScript 都提供了对应的编译支持，只是配置方式与旧版不同。如果使用 Babel，需要显式启用装饰器插件并指定版本参数，否则会与遗留的装饰器行为产生冲突。下面是一个典型配置示例。

{
  "presets": [
    ["@babel/preset-env", {
      "shippedProposals": true,
      "targets": "> 0.25%, not dead"
    }]
  ],
  "plugins": [
    ["@babel/plugin-proposal-decorators", { "version": "2023-11" }]
  ]
}

这个配置中 shippedProposals 会自动启用部分已进入 Stage 4 的提案转换，而装饰器则需要通过插件单独开启。version 参数指定的是装饰器提案的版本，旧项目如果使用 legacy 模式，升级时需要注意迁移成本。因此，在团队中引入 Stage 3 特性时，最好先完成小范围验证，避免影响现有构建链路。

二、装饰器提案：从实验语法到标准化

装饰器最早由 TypeScript 和 Babel 以实验性语法形式引入，用于给类和类成员添加元编程能力。旧版装饰器与当前 Stage 3 提案在参数结构和调用时机上存在较大不同，因此直接沿用旧写法会在新标准下面临兼容问题。新版装饰器采用 (value, context) 的形式，context 对象携带了成员名称、类型以及附加元数据的能力。

新版装饰器可以应用到类、方法、字段和访问器上，并且不再像旧版那样依赖 Object.defineProperty 的包装逻辑，这让引擎优化变得更加容易。以一个方法装饰器为例，下面的代码会在调用方法前后输出日志，而不需要修改原类结构。

function logged(value, { kind, name }) {
  if (kind === 'method') {
    const original = value;
    return function(...args) {
      console.log(`调用方法 ${name}`);
      return original.apply(this, args);
    };
  }
}
class UserService {
  @logged
  getUser(id) {
    return { id, name: 'Alice' };
  }
}
const service = new UserService();
service.getUser(1);

这段代码定义了一个 logged 装饰器，它接收原始方法和上下文信息，如果 kind 为 method 就返回一个包装函数。类装饰器也可以用于依赖注入或自动注册，但要注意装饰器函数的返回值语义：对于方法装饰器，返回新函数会替换原方法；对于类装饰器，返回新类才会替换原类。理解这些细节能帮助开发者避免出现运行时行为不符合预期的问题。

三、Record与Tuple、Temporal：不可变数据与现代化日期

Record 与 Tuple 是 Stage 2 提案，它们为 JavaScript 提供了原生不可变的数据结构。Record 使用 #{} 语法，Tuple 使用 #[] 语法，与普通对象和数组的区别在于：一旦创建，内容不可修改，并且可以按值比较，而不是按引用比较。这一特性对状态管理框架和缓存机制有很大吸引力。

const record = #{ name: 'Alice', age: 30 };
const tuple = #[1, 2, 3];
// 不可变，尝试修改会报错
// record.name = 'Bob'; // TypeError
// tuple[0] = 9; // TypeError

由于 Record 和 Tuple 只能包含原始值以及其他 Record 或 Tuple，因此它们天然支持深度比较。未来像 React.memo 或 useMemo 的依赖数组就能直接使用不可变结构来判断变化，而不需要手动编写浅比较逻辑。需要注意的是，该提案目前仍处于 Stage 2，语法可能还会微调，而且浏览器原生支持尚未普及，需要借助 polyfill 或转译器才能使用。

Temporal 提案则致力于解决 Date 对象的种种历史问题。Date 对象可变、时区处理不一致、解析行为依赖实现，这些长期困扰前端和后端开发者。Temporal 提供了 Temporal.PlainDate、Temporal.PlainTime、Temporal.ZonedDateTime 等一组不可变对象，每个对象只负责一个明确的时间概念。

const now = Temporal.Now.plainDateTimeISO();
const nextWeek = now.add({ days: 7 });
console.log(nextWeek.toString());

上面的 plainDateTimeISO 表示不带时区的本地日期时间，调用 add 方法返回一个全新的实例，原对象不受影响。这种设计避免了日期计算中意外修改原值的常见问题。目前 Temporal 已经进入 Stage 3，部分 API 已经在浏览器实验版本中实现，可以先在工具型函数中逐步引入。

四、管道操作符与模式匹配：更流畅的函数组合

管道操作符提案旨在解决多级函数嵌套调用可读性差的问题。目前两种主流语法风格分别是 Hack 风格和 F# 风格，Stage 2 阶段仍在讨论采用哪一种。Hack 风格使用占位符 %，F# 风格则要求右侧函数只接收一个参数。以字符串处理为例，F# 风格可以写出从左到右的数据流。

const result = "hello"
  |> (text => text.toUpperCase())
  |> (text => text.split('').reverse().join(''));
console.log(result);

这种写法避免了 reverse(join(split(toUpperCase(text)))) 这类从内向外阅读的困扰。不过管道操作符目前还处于 Stage 2，语法尚未最终确定，而且两种风格的分歧可能影响它在标准化过程中的推进速度。如果现在就将其用于生产代码，需要为后续可能的语法调整预留重构空间。

模式匹配提案则为 JavaScript 引入了类似函数式语言中的 match 表达式，能够根据值的结构或条件进行分支处理，替代冗长的 if-else 或 switch。它的语法仍在快速变化，下面是一个概念性示例。

const result = match (status) {
  when (status === 200) => 'OK',
  when (status === 404) => 'Not Found',
  default => 'Unknown'
};

模式匹配不仅能匹配字面量，还可以解构对象、数组，并支持守卫条件。对于状态机、表单校验和复杂数据解析场景，这种表达能力可以显著减少嵌套和重复代码。但考虑到该提案仍处于早期阶段，建议保持关注，等待进入 Stage 3 后再做生产评估。