前端框架响应式各写各的，今天 JavaScript 把它做进了语言层

十年来，前端框架的响应式系统几乎是前端分裂最严重的地方。

React 用 setState 加 Fiber 调度，Vue 用 Proxy 加依赖追踪，Solid 最早押注 Signals，Angular 花了几年时间从 Zone.js 迁移到 Signal API，Svelte 也有自己的 store。每个框架都自成一派，跨框架共享状态逻辑几乎不可能。

2026 年，TC39 的原生 Signals 提案到了 Stage 2，Chrome 和 Firefox Nightly 已经实现了它。这个提案做的事很简单：把响应式做进 JavaScript 语言层，让所有框架都能用同一套原语。

// 不需要任何框架，不需要任何 npm 包
const counter = new Signal.State(0);
const doubled = new Signal.Computed(() => counter.get() * 2);

// 订阅变化
Signal.sub(() => {
  console.log(`当前: ${counter.get()}, 两倍: ${doubled.get()}`);
});

counter.set(1);
// 输出: 当前: 1, 两倍: 2

Signal.State 是可写的 Signal，Signal.Computed 是派生值，Signal.sub 是订阅——三个东西构成了最小完整的响应式系统。它的设计目标是成为所有框架共享的地基，而不是替代框架的渲染引擎。

为什么这是十年分裂的终结

框架互操作的核心障碍是响应式原语不统一。一个 Vue 组件里创建的响应式状态没法直接在 React 组件里读，要靠 Provider、Context 或者发布-订阅桥接。一旦语言层面有了标准 Signal，框架可以在底层用同一套响应式图谱，跨框架的状态共享变得自然。

这和当年 jQuery Deferred 割据、最终被 ES6 Promise 统一是同一类故事。Promise 统一了异步编程模型，Signals 统一的是响应式模型。

现在能怎么用

Stage 2 还不是最终标准，浏览器的实现也还在 Nightly 阶段。如果你想现在就在项目里用，可以装 signal-polyfill，它实现了和提案一致的 API，任何框架都能接入。

对框架作者来说，这是必须关注的方向。对应用开发者来说，理解 Signals 的心智模型——精确追踪依赖、细粒度更新、推模型而非拉模型——无论你用哪个框架都用得上。

下一个节点是 Stage 3，届时会有更稳定的规范和更多浏览器实验性实现。按现在的推进速度，Stage 4 可能在 2027 年到来。