Signals 响应式原语深度解析：从 TC39 提案到框架实战

过去两年，「Signals」这个词在前端社区出现的频率呈指数级增长。从 Solid.js 率先采用，到 Angular 16 正式引入，再到 Preact、Qwik 跟进，甚至 React 团队也在探索类似机制——Signals 响应式原语正在重新定义前端框架的更新策略。2024 年 TC39 正式提出的 Signals 提案（Stage 1），更是将其推向了语言标准的高度。

如果你还在用 useState + useEffect 的组合拳处理每一个状态变化，或者在 Vue 的 computed 和 watch 之间纠结，那么理解 Signals 的底层机制将彻底改变你对响应式编程的认知。本文将从原理到实战，带你深入理解这个可能成为 JavaScript 下一代基础设施的技术。

🔬 一、Signals 核心原理：为什么它比现有方案更优

1.1 传统响应式的问题

在理解 Signals 之前，先看看现有方案的痛点。

React 的重渲染模型：

// ❌ React：状态变化触发整个组件树重渲染
function Parent() {
  const [count, setCount] = useState(0);
  console.log('Parent rendered'); // 每次 count 变化都会执行

  return (
    <div>
      <ChildA /> {/* 与 count 无关，但会被重渲染 */}
      <ChildB count={count} />
    </div>
  );
}

即使使用 React.memo、useMemo、useCallback，开发者仍然需要手动管理渲染边界。在大型应用中，这导致了大量不必要的计算和 DOM 操作。

Vue 的响应式追踪：

// ✅ Vue 3：自动追踪依赖，但仍有编译时开销
const count = ref(0);
const doubled = computed(() => count.value * 2);

// 模板中的响应式追踪依赖编译器转换
// <template> 中的 {{ doubled }} 会被编译为 effect 函数

Vue 3 的响应式系统已经很优秀，但它的追踪发生在组件粒度——一个组件内的任何响应式数据变化都会触发整个组件的重新渲染。

1.2 Signals 的本质

Signal 是一个可观察的值容器，它将「值的存储」和「值的消费」解耦。核心思想是：

📌 **记住：**Signal 不是新的 API，而是一种编程范式——推拉结合（Push/Pull）的细粒度响应式。当值变化时，只有真正依赖这个值的计算和 DOM 节点会被更新，精确到单个文本节点。

// Signals 的核心抽象
// ✅ 正确写法：细粒度响应式
const count = signal(0);          // 创建一个信号
const doubled = computed(() => count.value * 2);  // 派生计算

effect(() => {
  console.log(`Count: ${count.value}, Doubled: ${doubled.value}`);
  // 只有当 count 或 doubled 变化时才重新执行
});

count.value = 5;  // 触发 effect，输出 "Count: 5, Doubled: 10"

1.3 推拉结合模型解析

Signals 的核心创新在于其**推拉结合（Push/Pull）**的更新策略：

这种设计避免了两个极端：

• ❌ 纯推送（Push）：每个变化都立即传播，可能导致冗余计算
• ❌ 纯拉取（Pull）：需要轮询检查变化，效率低下

⚡ **关键结论：**推拉结合模型让 Signals 在保持精确更新的同时，避免了不必要的计算。这是它优于传统 Observable 和 Vue 响应式的核心原因。

🛠 二、五大框架 Signals 实现对比

2.1 各框架实现一览

2.2 Solid.js：Signals 的标杆实现

Solid.js 是最早也是最彻底采用 Signals 的框架。它的核心特点是没有虚拟 DOM——Signals 直接驱动 DOM 更新。

// Solid.js：完整的 Signals 使用示例
import { createSignal, createEffect, createMemo, For } from 'solid-js';

function TodoApp() {
  const [todos, setTodos] = createSignal([]);
  const [input, setInput] = createSignal('');

  // createMemo：自动追踪依赖，惰性求值
  const incompleteCount = createMemo(() =>
    todos().filter(t => !t.completed).length
  );

  // createEffect：副作用，自动追踪依赖
  createEffect(() => {
    console.log(`待办事项数量: ${todos().length}`);
    console.log(`未完成数量: ${incompleteCount()}`);
  });

  const addTodo = () => {
    if (!input().trim()) return;
    setTodos(prev => [...prev, {
      id: Date.now(),
      text: input(),
      completed: false
    }]);
    setInput('');
  };

  return (
    <div>
      <input
        value={input()}
        onInput={e => setInput(e.target.value)}
        onKeyPress={e => e.key === 'Enter' && addTodo()}
      />
      <button onClick={addTodo}>添加</button>
      <p>未完成: {incompleteCount()}</p>
      {/* For 组件：列表响应式更新，只有变化的项会重新渲染 */}
      <For each={todos()}>
        {(todo) => (
          <div>
            <input
              type="checkbox"
              checked={todo.completed}
              onChange={() => {
                setTodos(prev =>
                  prev.map(t =>
                    t.id === todo.id
                      ? { ...t, completed: !t.completed }
                      : t
                  )
                );
              }}
            />
            <span style={{
              'text-decoration': todo.completed ? 'line-through' : 'none'
            }}>
              {todo.text}
            </span>
          </div>
        )}
      </For>
    </div>
  );
}

💡 **提示：**Solid.js 中调用 signal 时用函数调用形式 count() 而不是属性访问 count.value。这是有意为之——函数调用让依赖追踪更明确，也避免了代理（Proxy）的性能开销。

2.3 Angular Signals：渐进式迁移的典范

Angular 的 Signals 设计非常务实——它没有推翻已有的 Zone.js 机制，而是作为补充逐步引入。

// Angular Signals：组件级使用
import { Component, signal, computed, effect } from '@angular/core';

@Component({
  selector: 'app-counter',
  template: `
    <div>
      <p>当前计数: {{ count() }}</p>
      <p>双倍值: {{ doubled() }}</p>
      <p>是否为偶数: {{ isEven() ? '是' : '否' }}</p>
      <button (click)="increment()">+1</button>
      <button (click)="decrement()">-1</button>
      <button (click)="reset()">重置</button>
    </div>
  `
})
export class CounterComponent {
  // writable signal：可读可写
  count = signal(0);

  // computed：派生只读信号
  doubled = computed(() => this.count() * 2);
  isEven = computed(() => this.count() % 2 === 0);

  constructor() {
    // effect：副作用，自动追踪依赖
    effect(() => {
      console.log(`计数变化: ${this.count()}`);
      // 可以在这里做日志、持久化等操作
    });
  }

  increment() {
    // .update() 方法基于当前值计算新值
    this.count.update(c => c + 1);
  }

  decrement() {
    this.count.update(c => c - 1);
  }

  reset() {
    // .set() 方法直接设置新值
    this.count.set(0);
  }
}

2.4 TC39 Signals 提案：走向语言标准

TC39 Signals 提案（由 Rob Eisenberg 和 Yehuda Katz 主导）旨在将 Signals 作为 JavaScript 语言原生特性。

// TC39 Signals 提案 API（Stage 1，API 可能变化）
// 需要 polyfill: npm install @preact/signals-core

// 创建信号
const count = new Signal.State(0);
const name = new Signal.State('World');

// 创建计算信号（惰性求值）
const greeting = new Signal.Computed(() => {
  return `Hello, ${name.get()}! Count is ${count.get()}`;
});

// 创建观察者（类似 effect）
const watcher = new Signal.subtle.Watcher(() => {
  console.log('值已更新:', greeting.get());
});

// 开始观察
watcher.watch(greeting);

// 修改信号值
count.set(1);  // 触发 watcher，输出 "Hello, World! Count is 1"
name.set('Signals');  // 触发 watcher，输出 "Hello, Signals! Count is 1"

⚠️ **警告：**TC39 Signals 提案目前处于 Stage 1，API 设计尚未最终确定。生产环境请使用各框架的成熟实现，而非直接使用提案 API。

🚀 三、性能对比与实战优化

3.1 性能基准测试

在 10,000 个节点的 TodoMVC 场景下的性能对比：

⚡ **关键结论：**Solid.js 在所有指标上都表现最优，但代价是需要完全不同的编程范式。Angular Signals 则在保持现有开发体验的同时，带来了显著的性能提升。

3.2 自定义 Signals 实现

理解 Signals 最好的方式是自己实现一个。以下是一个生产可用的简化版本：

// 自定义 Signals 实现（约 60 行，覆盖核心功能）

// 全局上下文：追踪当前正在执行的 effect
let currentEffect = null;
const effectStack = [];

class Signal {
  constructor(initialValue) {
    this._value = initialValue;
    this._subscribers = new Set();  // 依赖此 signal 的 effect
  }

  // 读取值时自动追踪依赖
  get value() {
    if (currentEffect) {
      this._subscribers.add(currentEffect);
    }
    return this._value;
  }

  // 写入值时触发更新
  set value(newValue) {
    if (this._value === newValue) return;  // 值未变化则跳过
    this._value = newValue;
    this._notify();
  }

  _notify() {
    // 批量执行：避免同步递归导致的栈溢出
    const effects = [...this._subscribers];
    for (const effect of effects) {
      effect._update();
    }
  }
}

class Computed {
  constructor(computeFn) {
    this._computeFn = computeFn;
    this._value = undefined;
    this._dirty = true;  // 标记是否需要重新计算
    this._subscribers = new Set();
    this._dependencies = new Set();
  }

  get value() {
    // 拉取阶段：只有被标记为脏时才重新计算
    if (this._dirty) {
      // 收集依赖
      const prevEffect = currentEffect;
      currentEffect = this;
      // 清除旧依赖
      for (const dep of this._dependencies) {
        dep._subscribers.delete(this);
      }
      this._dependencies.clear();
      // 重新计算
      this._value = this._computeFn();
      this._dirty = false;
      currentEffect = prevEffect;
    }

    // 如果有上层 effect，建立订阅关系
    if (currentEffect) {
      this._subscribers.add(currentEffect);
    }
    return this._value;
  }

  _update() {
    this._dirty = true;
    // 推送阶段：级联标记下游 computed 为脏
    for (const sub of this._subscribers) {
      if (sub instanceof Computed) {
        sub._update();
      } else if (sub._update) {
        sub._update();
      }
    }
  }
}

class Effect {
  constructor(effectFn) {
    this._effectFn = effectFn;
    this._dependencies = new Set();
    this._scheduled = false;
    this._run();
  }

  _run() {
    // 清除旧依赖
    for (const dep of this._dependencies) {
      dep._subscribers.delete(this);
    }
    this._dependencies.clear();

    // 执行 effect 并收集依赖
    const prevEffect = currentEffect;
    currentEffect = this;
    this._effectFn();
    currentEffect = prevEffect;
  }

  _update() {
    // 使用微任务批量调度，避免同步重复执行
    if (this._scheduled) return;
    this._scheduled = true;
    queueMicrotask(() => {
      this._scheduled = false;
      this._run();
    });
  }
}

// 便捷工厂函数
function signal(value) {
  return new Signal(value);
}

function computed(fn) {
  return new Computed(fn);
}

function effect(fn) {
  return new Effect(fn);
}

3.3 实战：用自定义 Signals 构建表单验证

// 使用自定义 Signals 实现表单验证
const email = signal('');
const password = signal('');
const confirmPassword = signal('');

// 派生状态：自动追踪依赖
const emailValid = computed(() => {
  const re = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
  return re.test(email.value);
});

const passwordStrength = computed(() => {
  const pwd = password.value;
  if (pwd.length === 0) return { level: 0, text: '请输入密码' };
  if (pwd.length < 8) return { level: 1, text: '密码太短' };
  if (!/[A-Z]/.test(pwd)) return { level: 2, text: '需要大写字母' };
  if (!/[0-9]/.test(pwd)) return { level: 2, text: '需要数字' };
  if (!/[^A-Za-z0-9]/.test(pwd)) return { level: 3, text: '建议添加特殊字符' };
  return { level: 4, text: '密码强度：优秀' };
});

const passwordsMatch = computed(() => {
  return password.value.length > 0 &&
         password.value === confirmPassword.value;
});

const formValid = computed(() => {
  return emailValid.value &&
         passwordStrength.value.level >= 3 &&
         passwordsMatch.value;
});

// 副作用：实时更新 UI
effect(() => {
  const btn = document.getElementById('submit-btn');
  if (btn) {
    btn.disabled = !formValid.value;
    btn.textContent = formValid.value ? '注册' : '请完善表单';
  }
});

// 模拟用户输入
email.value = 'user@example.com';    // emailValid -> true
password.value = 'MyP@ss123';        // strength -> 4
confirmPassword.value = 'MyP@ss123'; // passwordsMatch -> true
// formValid -> true，按钮启用

💡 **提示：**这个自定义实现使用了微任务（queueMicrotask）来批量调度更新，避免了在一个同步代码块中多次修改 signal 导致的重复执行。这是生产级 Signals 实现的关键优化。

💡 四、迁移策略与最佳实践

4.1 渐进式迁移路径

如果你的项目已经在使用 Vue 或 Angular，迁移到 Signals 是渐进式的。但如果你在使用 React，需要更谨慎：

4.2 避坑指南

坑点一：不要在 computed 中产生副作用

// ❌ 错误写法：computed 中发送请求
const userData = computed(() => {
  const data = fetch(`/api/user/${userId.value}`);  // 每次依赖变化都会触发！
  return data;
});

// ✅ 正确写法：副作用放在 effect 中
const userId = signal(1);
const userData = signal(null);

effect(async () => {
  // effect 中处理异步副作用
  const response = await fetch(`/api/user/${userId.value}`);
  userData.value = await response.json();
});

坑点二：避免循环依赖

// ❌ 错误写法：A 依赖 B，B 依赖 A
const a = computed(() => b.value + 1);
const b = computed(() => a.value + 1);  // 死循环！

// ✅ 正确写法：引入中间状态
const base = signal(0);
const a = computed(() => base.value + 1);
const b = computed(() => base.value + 2);

坑点三：注意异步上下文中的依赖追踪

// ❌ 错误写法：异步函数中的依赖不会被追踪
const data = computed(async () => {
  const res = await fetch(`/api/${id.value}`);  // id 的变化不会触发重新计算
  return res.json();
});

// ✅ 正确写法：使用 effect + signal 组合
const id = signal(1);
const data = signal(null);
const loading = signal(false);

effect(() => {
  loading.value = true;
  fetch(`/api/${id.value}`)
    .then(res => res.json())
    .then(json => {
      data.value = json;
      loading.value = false;
    });
});

⚠️ **警告：**Signals 的依赖追踪是同步的——只有在执行函数体期间读取的 signal 才会被追踪。所有异步操作（await、.then、setTimeout）中的信号读取不会建立依赖关系。

4.3 何时使用 Signals

4.4 Signals vs 传统状态管理：实战案例对比

为了更直观地展示 Signals 的优势，我们用一个真实场景来对比：构建一个商品筛选面板，包含价格范围滑块、分类多选、排序切换三个联动筛选条件。

传统 Redux 方案：

// ❌ Redux：需要定义 action、reducer、selector，代码分散
// store/filterSlice.js
const filterSlice = createSlice({
  name: 'filter',
  initialState: { priceRange: [0, 1000], categories: [], sortBy: 'price' },
  reducers: {
    setPriceRange: (state, action) => { state.priceRange = action.payload; },
    toggleCategory: (state, action) => {
      const idx = state.categories.indexOf(action.payload);
      if (idx >= 0) state.categories.splice(idx, 1);
      else state.categories.push(action.payload);
    },
    setSortBy: (state, action) => { state.sortBy = action.payload; },
  },
});

// 组件中：需要手动 memoize 筛选结果
const filteredProducts = useSelector(state => {
  return state.products.filter(p =>
    p.price >= state.filter.priceRange[0] &&
    p.price <= state.filter.priceRange[1] &&
    (state.filter.categories.length === 0 ||
     state.filter.categories.includes(p.category))
  ).sort((a, b) => {
    if (state.filter.sortBy === 'price') return a.price - b.price;
    return b.rating - a.rating;
  });
});  // 任何 filter 变化都重新计算，即使结果相同

Signals 方案：

// ✅ Signals：声明式，代码集中，自动优化
const priceRange = signal([0, 1000]);
const categories = signal([]);
const sortBy = signal('price');
const products = signal([]);  // 从 API 获取的商品列表

// 自动追踪依赖，惰性求值
const filteredProducts = computed(() => {
  return products.value
    .filter(p =>
      p.price >= priceRange.value[0] &&
      p.price <= priceRange.value[1] &&
      (categories.value.length === 0 ||
       categories.value.includes(p.category))
    )
    .sort((a, b) => {
      if (sortBy.value === 'price') return a.price - b.price;
      return b.rating - a.rating;
    });
});

// 统计信息也是派生状态，自动更新
const stats = computed(() => ({
  total: filteredProducts.value.length,
  avgPrice: filteredProducts.value.reduce((s, p) => s + p.price, 0)
            / (filteredProducts.value.length || 1),
}));

// 使用时直接读取，无需 selector、dispatch
console.log(`筛选结果: ${stats.value.total} 件商品`);
console.log(`平均价格: ¥${stats.value.avgPrice.toFixed(2)}`);

两种方案的代码量和可维护性差距一目了然。Redux 需要在三个文件（slice、store、组件）之间跳转，而 Signals 将所有逻辑集中在一处，依赖关系清晰可见。

4.5 与 RxJS 的关系：互补而非替代

很多开发者会问：Signals 和 RxJS（Reactive Extensions for JavaScript）有什么区别？它们都处理异步数据流，但设计理念完全不同。

📌 **记住：**Signals 处理的是「当前值是什么」，RxJS 处理的是「一系列事件如何组合」。如果你的需求是 UI 状态联动，用 Signals；如果你需要合并多个 WebSocket 流、做防抖节流、处理复杂的异步编排，RxJS 仍然是最佳选择。两者可以在同一个项目中共存。

🎯 总结

Signals 不是一个框架，而是一种响应式编程范式的进化。它的核心价值在于：

1. ✅ 精确更新：只有真正依赖变化值的 DOM 节点才会更新
2. ✅ 自动依赖追踪：无需手动声明依赖关系
3. ✅ 框架无关：TC39 提案意味着未来可能成为语言标准
4. ✅ 性能卓越：在大规模应用场景下，性能优势可达 5-10 倍

⚡ **关键结论：**如果你正在启动新项目且对性能有要求，Solid.js 是目前最成熟的 Signals 框架。如果你的项目已经在用 Angular，立即开始采用 Signals API。对于 React 项目，关注 Preact Signals 的兼容方案，或等待 React 团队的官方动向。

相关工具推荐：

• 🔧 Solid.js Playground — 在线体验 Signals
• 🔧 TC39 Signals Proposal — 提案原文
• 🔧 Preact Signals — React 兼容方案
• 🔧 jsjson.com JSON 工具 — 开发必备的在线工具箱