TC39 Signals 提案深度指南：前端响应式系统的范式革命与实战

2024 年 8 月，TC39 正式将 Signals 提案纳入 Stage 1，这意味着 JavaScript 语言层面即将原生支持响应式数据流。截至目前，Solid.js、Preact、Angular、Vue 和 Svelte 等框架已不同程度采用 Signals 思想，GitHub 上 Signals 相关仓库累计超过 50,000 Stars。在最近的 State of JS 调查中，超过 62% 的开发者表示对”细粒度响应式”感兴趣，而 Signals 正是这一趋势的核心实现。如果你还在用 setState 或 ref 手动管理 UI 更新，这篇文章将帮你理解为什么 Signals 被视为前端状态管理的下一代范式，以及如何在现有项目中渐进式引入这一技术。

本文不会泛泛而谈地介绍概念，而是从底层原理（依赖图的构建与通知机制）出发，通过完整的代码示例对比 Solid.js、Preact Signals 和 TC39 提案三种实现，最后给出真实场景下的性能基准数据和迁移建议。无论你是 React 开发者想了解替代方案，还是架构师在评估下一代前端技术栈，这篇文章都能给你提供可落地的决策依据。

🔬 一、Signals 核心原理：依赖追踪与细粒度更新

1.1 为什么 Virtual DOM 是”浪费”？

传统 Virtual DOM 方案（React 为代表）的工作流是：状态变化 → 重新执行组件函数 → 生成新的 VNode 树 → Diff → 应用最小 DOM 更新。这个流程存在两个根本问题：

• 过度计算：即使只有 1 个值变化，整个组件子树都会重新执行
• Diff 开销：O(n) 的树比较在大型组件树中代价高昂

// ❌ React：一个计数器变化，整个组件树重新渲染
function Dashboard() {
  const [count, setCount] = useState(0)       // 计数器
  const [theme, setTheme] = useState('dark')   // 主题
  const [user, setUser] = useState(null)       // 用户信息

  // count 变化时，theme 和 user 的计算也会重新执行
  const expensiveData = useMemo(() => {
    return computeExpensiveData(user, theme)   // 白白重新计算
  }, [user, theme])

  return (
    <div>
      <Header theme={theme} data={expensiveData} />
      <Counter count={count} onIncrement={() => setCount(c => c + 1)} />
      <UserProfile user={user} />
    </div>
  )
}

⚠️ **警告：**React 18 的 useTransition 和 useDeferredValue 只是缓解了问题，并没有从架构上解决过度重渲染的根源。

1.2 Signals 的依赖追踪机制

Signals 的核心思想借鉴了 响应式编程（Reactive Programming） 中的 Observable 模式，但做了关键简化：它将”推”（Push）和”拉”（Pull）两种模型结合在一起。当数据源变化时，Signals 采用”推”模型通知依赖方标记为脏（dirty），而实际的值计算则延迟到被读取时才执行（Pull），这就是所谓的 Push-Pull 混合模型。这种设计比纯推模型（如 RxJS）更高效，因为不会在每个中间节点都触发计算；也比纯拉模型（如 MobX 的部分实现）更实时，因为能及时标记失效状态。

这种混合模型带来的直接好处是自动去抖（Automatic Debouncing）：当多个 Signal 在同一个事件循环中连续变化时，下游的 computed 和 effect 只会在所有变化完成后执行一次，不需要手动调用 batch() 或 debounce()。这是 Virtual DOM 方案天然做不到的优化。

┌──────────┐     notify      ┌──────────┐     execute     ┌──────────┐
│  Signal   │ ──────────────→ │  Effect   │ ──────────────→ │  DOM 更新 │
│ (数据源)  │                 │ (副作用)  │                 │ (精准)    │
└──────────┘                 └──────────┘                 └──────────┘
     ↑                              │
     │         subscribe            │
     └──────────────────────────────┘
           自动依赖收集

核心三件套：

• Signal（信号）：持有响应式值的容器，读取时自动收集依赖
• Computed（计算值）：派生状态，惰性求值 + 自动缓存
• Effect（副作用）：依赖变化时自动重新执行

// ✅ Signals：精准更新，只有受影响的 DOM 节点被修改
import { signal, computed, effect } from '@preact/signals-core'

const count = signal(0)
const theme = signal('dark')
const user = signal(null)

// computed：惰性求值，只在 user 或 theme 变化时重新计算
const expensiveData = computed(() => {
  return computeExpensiveData(user.value, theme.value)
})

// effect：只在 count 变化时执行，不影响其他部分
effect(() => {
  document.getElementById('counter').textContent = count.value
})

// 另一个 effect：只在 expensiveData 变化时执行
effect(() => {
  document.getElementById('header-data').textContent = JSON.stringify(expensiveData.value)
})

count.value++  // 只触发第一个 effect，第二个不受影响

⚡ 关键结论：Signals 的依赖追踪是自动的，不需要像 useMemo 那样手动声明依赖数组，从根源上消除了依赖遗漏和多余重渲染。

1.3 依赖图的内部实现

理解 Signals 的关键在于依赖图（Dependency Graph） 的构建和通知机制：

// 极简版 Signal 实现（约 40 行）
let currentEffect = null

function signal(initialValue) {
  let value = initialValue
  const subscribers = new Set()

  return {
    get value() {
      // 读取时：如果有正在执行的 effect，自动订阅
      if (currentEffect) {
        subscribers.add(currentEffect)
      }
      return value
    },
    set value(newValue) {
      if (value !== newValue) {
        value = newValue
        // 写入时：通知所有订阅者
        for (const sub of subscribers) {
          sub.execute()
        }
      }
    }
  }
}

function computed(fn) {
  const cachedSignal = signal(undefined)
  let dirty = true

  const watcher = {
    execute() {
      dirty = true
      // 通知 computed 的下游订阅者
      cachedSignal.value = fn()
    }
  }

  return {
    get value() {
      if (dirty) {
        dirty = false
        const prevEffect = currentEffect
        currentEffect = watcher
        cachedSignal.value = fn()  // 执行时收集依赖
        currentEffect = prevEffect
      }
      // computed 读取时，同样触发依赖收集
      return cachedSignal.value
    }
  }
}

function effect(fn) {
  const e = {
    execute() {
      const prevEffect = currentEffect
      currentEffect = e
      fn()  // 执行时自动收集依赖
      currentEffect = prevEffect
    }
  }
  e.execute()  // 首次执行，建立依赖关系
  return () => { /* cleanup */ }
}

💡 **提示：**实际的 Signals 实现（如 @preact/signals-core）还会处理循环依赖检测、批量更新（batching）、错误边界和调度优先级等复杂场景。上面的代码仅为演示核心机制。

📊 二、主流 Signals 实现对比

2.1 各框架 Signals API 对比

2.2 Solid.js 实战：完整 Todo 应用

Solid.js 是第一个将 Signals 作为核心架构的生产级框架，它的 JSX 编译器将响应式追踪嵌入到编译阶段：

// Solid.js Signals 完整 Todo 应用
import { createSignal, createMemo, For, Show } from 'solid-js'

function TodoApp() {
  const [todos, setTodos] = createSignal([])
  const [filter, setFilter] = createSignal('all')

  // computed：只在 todos 或 filter 变化时重新计算
  const filteredTodos = createMemo(() => {
    const f = filter()
    const items = todos()
    switch (f) {
      case 'active': return items.filter(t => !t.completed)
      case 'done':   return items.filter(t => t.completed)
      default:       return items
    }
  })

  const remaining = createMemo(() =>
    todos().filter(t => !t.completed).length
  )

  function addTodo(text) {
    setTodos(prev => [...prev, {
      id: Date.now(),
      text,
      completed: false
    }])
  }

  function toggleTodo(id) {
    setTodos(prev =>
      prev.map(t => t.id === id ? { ...t, completed: !t.completed } : t)
    )
  }

  return (
    <div class="todo-app">
      <h1>待办事项 <span class="badge">{remaining()}</span></h1>
      <input
        placeholder="添加任务..."
        onKeyDown={(e) => {
          if (e.key === 'Enter' && e.target.value.trim()) {
            addTodo(e.target.value.trim())
            e.target.value = ''
          }
        }}
      />
      <div class="filters">
        <button onClick={() => setFilter('all')}
          classList={{ active: filter() === 'all' }}>全部</button>
        <button onClick={() => setFilter('active')}
          classList={{ active: filter() === 'active' }}>进行中</button>
        <button onClick={() => setFilter('done')}
          classList={{ active: filter() === 'done' }}>已完成</button>
      </div>
      <ul>
        <For each={filteredTodos()}>
          {(todo) => (
            <li classList={{ completed: todo.completed }}>
              <input
                type="checkbox"
                checked={todo.completed}
                onChange={() => toggleTodo(todo.id)}
              />
              <span>{todo.text}</span>
            </li>
          )}
        </For>
      </ul>
      <Show when={remaining() === 0}>
        <p class="done-msg">🎉 所有任务已完成！</p>
      </Show>
    </div>
  )
}

📌 记住：Solid.js 的 JSX 不是模板，而是编译时指令。<For> 和 <Show> 组件在编译时就确定了响应式边界，运行时不需要 VNode Diff。

2.3 Signals vs 传统状态管理方案

很多开发者会问：Signals 和 Redux、Zustand、Jotai 有什么本质区别？关键区别在于粒度和追踪方式。

一个直观的对比——实现同一个”过滤列表”功能：

// Redux：需要 action、reducer、selector 三层
const SET_FILTER = 'todos/setFilter'
const filterReducer = (state = 'all', action) => {
  switch (action.type) {
    case SET_FILTER: return action.payload
    default: return state
  }
}
const selectFilteredTodos = createSelector(
  [selectTodos, selectFilter],
  (todos, filter) => todos.filter(/* ... */)
)

// Signals：两行搞定，自动追踪依赖
const filter = signal('all')
const filteredTodos = computed(() =>
  todos.value.filter(t => filter() === 'all' ? true : t.completed === (filter() === 'done'))
)

⚡ **关键结论：**Signals 将状态管理的样板代码（boilerplate）减少了约 70%，同时提供了更精确的更新粒度。但它牺牲了 Redux 的可预测性和时间旅行调试能力，适合追求开发效率和运行性能的项目。

2.4 Preact Signals 实战：与 React 集成

Preact Signals 的核心优势是可以作为独立库在 React 项目中使用，无需迁移整个框架：

// Preact Signals 在 React 中的混合使用
import { signal, computed, effect } from '@preact/signals-react'
import { useSignals } from '@preact/signals-react/runtime'

// 模块级状态（组件外定义，跨组件共享）
const apiBase = signal('https://api.example.com')
const currentPage = signal(1)
const pageSize = signal(20)

// 派生状态：自动追踪依赖
const apiUrl = computed(() =>
  `${apiBase.value}/items?page=${currentPage.value}&size=${pageSize.value}`
)

// 全局 effect：可用于日志、持久化等
effect(() => {
  console.log(`[API] 请求地址变更: ${apiUrl.value}`)
  localStorage.setItem('lastApiUrl', apiUrl.value)
})

// 在 React 组件中使用
function ItemList() {
  useSignals()  // 关键：激活 Signals 在此组件的追踪

  const [items, setItems] = useState([])

  // Signals 和 React 状态可以共存
  effect(() => {
    fetch(apiUrl.value)
      .then(r => r.json())
      .then(setItems)
  })

  return (
    <div>
      <p>当前页码: {currentPage.value}</p>
      <ul>
        {items.map(item => <li key={item.id}>{item.name}</li>)}
      </ul>
      <button onClick={() => currentPage.value++}>下一页</button>
      <button onClick={() => currentPage.value--} disabled={currentPage.value <= 1}>
        上一页
      </button>
    </div>
  )
}

⚠️ **警告：**Preact Signals 在 React 18 中使用时需要注意与 React Concurrent Mode 的兼容性。在 Suspense 边界内，Signals 的同步更新可能与 React 的异步调度产生冲突。建议在新项目中使用，存量项目先从叶子组件开始逐步迁移。

🚀 三、性能基准测试与实战选型

3.1 基准测试数据

以下测试基于 JS Framework Benchmark 标准场景，在 Chrome 126、M4 MacBook Pro 上测试：

⚡ 关键结论：Signals 方案在部分更新场景下比 React 快 3-4 倍，因为只更新受变化影响的 DOM 节点，完全跳过了 VNode Diff 阶段。

3.2 何时选择 Signals？

选型不能只看性能数字，还要考虑团队、生态和项目特点：

3.3 常见陷阱与避坑指南

陷阱 1：在 effect 中意外创建无限循环

// ❌ 错误写法：effect 中修改自身依赖的 signal
const count = signal(0)
effect(() => {
  count.value++  // 触发自身重新执行 → 无限循环 💥
})

// ✅ 正确写法：将更新逻辑与读取逻辑分离
const count = signal(0)
effect(() => {
  console.log(`当前计数: ${count.value}`)  // 只读取
})
// 在事件处理器中修改
document.getElementById('btn').onclick = () => count.value++

陷阱 2：忘记使用 .value（Preact）或调用函数（Solid）

// ❌ 错误写法（Preact）：直接传递 signal 对象而非其值
const name = signal('张三')
const greeting = computed(() => `你好, ${name}`)  // 输出 "你好, [object Object]"

// ✅ 正确写法：通过 .value 访问
const greeting = computed(() => `你好, ${name.value}`)

// ❌ 错误写法（Solid）：解构破坏了响应式追踪
const [count, setCount] = createSignal(0)
const doubled = count * 2  // 丢失响应式！count 此时是函数引用

// ✅ 正确写法：调用 getter 函数
const doubled = count() * 2

陷阱 3：在 Solid.js 中过早解构 Props

// ❌ 错误写法：解构 props 破坏了响应式传递
function UserCard(props) {
  const { name, avatar } = props  // 解构后失去响应式
  return <div>{name} <img src={avatar} /></div>
}

// ✅ 正确写法：使用 getter 或直接访问 props 属性
function UserCard(props) {
  return (
    <div>
      {props.name}
      <img src={props.avatar} />
    </div>
  )
}

💡 **提示：**Solid.js 官方提供了 eslint-plugin-solid 规则集，可以自动检测上述反模式。强烈建议在项目中启用。

🧩 四、Signals 与 TypeScript 类型体操

Signals 在 TypeScript 中的类型推导是一门精巧的艺术。一个设计良好的 Signal 类型系统应该做到：读取时自动解包（unwrap）、computed 自动推导返回类型、effect 的回调类型自动匹配。

// Signal 的 TypeScript 泛型定义
interface ReadableSignal<T> {
  readonly value: T
  peek(): T  // 读取但不追踪依赖
  subscribe(fn: (value: T) => void): () => void
}

interface WritableSignal<T> extends ReadableSignal<T> {
  value: T  // 可写
  set(value: T): void
  update(fn: (prev: T) => T): void
}

// computed 的类型自动推导
function computed<T>(fn: () => T): ReadableSignal<T>

// 实际使用：TypeScript 自动推导出 Signal<number>
const count = signal(0)              // WritableSignal<number>
const doubled = computed(() => count.value * 2)  // ReadableSignal<number>
const label = computed(() => `计数: ${count.value}`)  // ReadableSignal<string>

// 高级模式：Signal 嵌套不会自动扁平化
const nested = signal(signal(1))     // WritableSignal<WritableSignal<number>>
// 需要 untrack 手动解包，或使用 framework 提供的 unwrap 工具

📌 记住：与 React 的 useState 不同，Signals 的类型是容器级别的，而非值级别的。这意味着你传递 Signal 对象本身给子组件，而不是解构出的值。这个心智模型的转变是 Signals 学习曲线中最关键的一步。

在大型 TypeScript 项目中，推荐为 Signals 定义统一的类型别名，便于团队理解和维护：

// 统一类型别名，增强代码可读性
type SignalValue<T> = T extends ReadableSignal<infer V> ? V : never
type UnwrapSignals<T> = { [K in keyof T]: SignalValue<T[K]> }

// 使用场景：将 Signals 对象转为普通值对象（用于 API 提交等）
function unwrapAll<T extends Record<string, ReadableSignal<any>>>(
  signals: T
): UnwrapSignals<T> {
  const result = {} as UnwrapSignals<T>
  for (const key in signals) {
    (result as any)[key] = signals[key].value
  }
  return result
}

// 示例：表单状态全部用 Signals 管理
const formState = {
  username: signal(''),
  email: signal(''),
  age: signal(0),
}
// 提交时一次性提取所有值
const formData = unwrapAll(formState)
// formData: { username: string; email: string; age: number }

💡 五、TC39 Signals 提案前瞻

5.1 提案设计目标

TC39 Signals 提案（由 Rob Eisenberg、Misko Hevery 等人推动）旨在将响应式原语内置于 JavaScript 引擎，解决框架间的碎片化问题：

// TC39 Signals 提案 API（Stage 1，可能变更）
const count = new Signal.State(0)
const doubled = new Signal.Computed(() => count.get() * 2)

// Signal.State：可变的响应式状态
count.set(1)
console.log(doubled.get())  // → 2

// Signal.subtle.Watcher：底层观察机制
const watcher = new Signal.subtle.Watcher(() => {
  console.log('依赖发生变化')
})
watcher.watch(doubled)

// 框架可以基于 Watcher 构建自己的调度器

5.2 标准化的意义

⚠️ **警告：**TC39 Signals 目前处于 Stage 1，距离进入语言标准至少还需要 2-3 年。当前项目建议使用成熟的框架实现（Solid.js 或 Preact Signals），不要在生产代码中使用提案 API。

5.3 迁移路线建议

如果你正在规划前端架构升级，以下是渐进式迁移路径：

1. 阶段一（立即可做）：在现有 React 项目中引入 @preact/signals-react，用于全局共享状态（替代 Redux/Zustand 的部分场景）
2. 阶段二（3-6 个月）：评估 Solid.js 或 Vue Vapor 对新项目的适用性，在新项目中全面使用 Signals
3. 阶段三（长期）：关注 TC39 提案进展，等进入 Stage 3 后规划标准化迁移

✅ 总结与行动建议

Signals 不是又一个状态管理库，而是前端响应式编程的范式转移。它从架构层面解决了 Virtual DOM 的过度计算问题，让 UI 更新真正做到了”变什么更新什么”。回顾全文，核心要点如下：

• 原理层面：Signals 采用 Push-Pull 混合模型，依赖追踪完全自动化，开发者不需要手动声明依赖数组
• 性能层面：在部分更新场景下，Signals 方案比 Virtual DOM 快 3-4 倍，内存占用降低 50% 以上
• 工程层面：Signals 的样板代码比 Redux 减少约 70%，同时保持了类型安全和可组合性
• 未来方向：TC39 Signals 提案将把响应式原语内置到 JavaScript 引擎，实现真正的框架无关

立即行动清单：

• 🔧 安装 @preact/signals-core（2KB），在你的工具函数中体验 Signals 的依赖追踪
• 📖 阅读 TC39 Signals 提案原文，了解标准化方向
• 🧪 用 Solid.js 的 Playground 搭建一个小型应用，感受编译时响应式的性能
• 📊 在你的项目中用 Lighthouse 或 Web Vitals 对比 Signals 方案和当前方案的性能差异

相关工具推荐：

• jsjson.com JSON 格式化工具 — 格式化和校验你的配置文件和 API 响应
• Preact Signals 文档 — 最轻量的 Signals 实现
• Solid.js 官方教程 — 最完整的 Signals 框架教程