2026年TC39提案：装饰器、时间相关概念与信号详解

自20世纪90年代末以来，怀疑论者几乎每年都会宣称JavaScript“已经完蛋”，但每次这种言论都被该语言证明是错误的。负责推动ECMAScript发展的TC39委员会一直在默默推进各项提案，这些提案正在改变人们编写日常代码的方式。

如果你使用全栈JavaScript、React或Next.js进行开发，那么目前正在审批流程中的几项提案值得你关注。它们并非那些引人注目的重大功能，而是那种能悄然消除你多年来一直使用却从未质疑过的冗余代码的改进。

以下是三项值得追踪的提案。

1. 原生装饰器即将登场

TypeScript 开发者多年来一直依赖 experimentalDecorators 编译器标志来使用装饰器功能。这一临时解决方案即将被取代。标准化的 Decorators 提案已进入第 3 阶段，这意味着浏览器和 JavaScript 运行时已经在开发其实际实现。

// before: relying on experimentalDecorators + reflect-metadata
class UserService {
  @logCall
  fetchUser(id: string) {
    return api.get(`/users/${id}`);
  }
}

更新后的规范放弃了基于 reflect-metadata 的旧设计，转而采用更可预测的方式：装饰器函数现在会接收它要装饰的值以及描述该值的上下文对象，并且可以返回该值的替代值。如果你曾遇到过 Babel 的装饰器实现与 TypeScript 自带实现版本不一致的问题，这一统一无疑是个好消息。

总结：如果你选择的框架——无论是 Angular 风格的依赖注入、MobX，还是类似 NestJS 的模式——都依赖于装饰器，那么在后续版本中你就不必再为编译器参数而烦恼了。

2. Temporal 几乎可以发布了

JavaScript 内置的 Date 对象近三十年来一直让人头疼。它不具备不可变性，处理时区的方式令人困惑，还提供了会引发错误的修改方法，就连经验丰富的工程师也会因此犯错。Temporal 是一个长期得到 Mozilla 贡献者及其他利益相关方支持的提案，如今已进入最终阶段，预计将在未来的 ECMAScript 版本中正式加入。

const meeting = Temporal.ZonedDateTime.from(
  "2026-09-14T10:00:00[America/New_York]"
);
const inTokyo = meeting.withTimeZone("Asia/Tokyo");

使用 Temporal，无需借助 moment.js 等库即可获得正确处理时区的日期时间，将会议时间转换到其他时区之类的操作也变得简单直接，无需手动计算时差。如果在 Next.js 应用中开发调度功能，这可以说是该语言带来的最重大的使用体验提升。

3. Signals：响应式状态的标准

React 的 useState、Vue 的 ref 以及 Solid 的 signals 都是在解决同一个核心问题：追踪随时间变化的值并对此类变化做出响应。TC39 的 Signals 提案旨在为 JavaScript 提供一种原生的响应式数据类型，让各种框架能够以此为基础进行开发，而非让每个生态系统都自行设计类似机制的实现方式。

这项提案目前仍处于初期阶段，但它所指向的方向十分明确——打个双关语——那就是减少 Redux、React 及其他状态管理库中重复的响应式逻辑，而在其底层使用更多可共享、可重用的构建模块。

这对您的技术栈意味着什么

• TypeScript 的优势将首先体现出来。用于装饰器和 Temporal 的更简洁、标准化的类型定义将会应用到您已使用的工具中。
• 您的 UI 层及样式设置，包括类似 Tailwind CSS 的工具，不会受到直接影响，但更快、更可靠的日期/时间处理功能意味着组件中不再需要那么多自定义的实用代码。
• 即便客户端库尚未完全采用 Temporal，Next.js 的服务器组件也很可能成为它的首个应用场景，尤其是在服务器端日期格式化方面。

TC39联合主席Rob Palmer在委员会更新中提到，现在在同一轮会议周期内有数项提案同时取得进展已属常见现象。这一趋势表明，过去几年中语言发展的速度确实加快了。

总结

这一切都不会改变你目前使用的JavaScript代码。但下次当你本能地想要使用moment.js，或为装饰器polyfill而苦恼时，请记住，已经有原生解决方案正在逐步被采纳。经验丰富的开发者总是会提前一两项提案掌握趋势，这样才能避免陷入困境——这也是他们往往反对在相关提案尚未最终确定时就采用可能带来技术债务的设计模式的原因。