前端框架Signal响应式革命：当细粒度更新击碎虚拟DOM神话——从Svelte 5 Runes到Angular Signals的深度实战指南（2026）

一、引言：虚拟DOM的黄昏？

2013年，React带着虚拟DOM横空出世，用「每次状态变化都重新渲染整个组件树，然后Diff出最小变更」的思路，终结了jQuery手动操作DOM的蛮荒时代。这个设计在随后十年里统治了前端界，催生了Vue、Preact等一众追随者。

但到了2026年，风向变了。

如果你关注前端社区最近两年的讨论，会发现一个有趣的现象：几乎所有「非React」框架的核心卖点，都指向同一个关键词——Signal。

Svelte 5用Runes重写了响应式系统。SolidJS从诞生起就把Signals作为核心抽象。Preact在2023年就引入了Signals库，如今已是官方推荐。Angular从v17开始全面拥抱Signals，到2026年的v20版本，Signal已经成为Angular应用的「一等公民」。就连Vue 3基于Proxy的响应式系统，在设计哲学上也与Signal殊途同归。

唯独React还在坚守虚拟DOM——即便React Compiler 1.0试图在编译阶段优化重渲染，底层的「组件级Diff」架构依然没变。

这不是框架间的「宗教战争」，而是一场关于更新粒度的技术革命。本文将从最底层的依赖追踪原理讲起，手撕Signal的实现，然后深入Svelte、SolidJS、Angular、Vue、Preact五大框架的具体实现，最后给出生产级的选型建议和迁移指南。

二、虚拟DOM的「隐性成本」：为什么我们需要更细粒度的更新？

在聊Signal之前，有必要先弄清楚：虚拟DOM到底「贵」在哪里。

2.1 组件级更新：React的阿克琉斯之踵

React的核心渲染模型可以简化为三条规则：

1. 状态变化触发组件函数重新执行
2. 重新执行生成新的虚拟DOM树
3. 新旧虚拟DOM Diff出变更，应用到真实DOM

// React 组件示例
function UserProfile({ userId }) {
  const [name, setName] = useState('')
  const [bio, setBio] = useState('')
  
  // 假设这里有一个巨大的列表
  const items = useMemo(() => {
    return generateExpensiveList(userId)
  }, [userId])
  
  return (
    <div>
      <input value={name} onChange={e => setName(e.target.value)} />
      <textarea value={bio} onChange={e => setBio(e.target.value)} />
      <ExpensiveList items={items} />
    </div>
  )
}

这个组件的性能问题很典型：当用户在输入框中打字（调用setName），整个UserProfile函数会重新执行。generateExpensiveList虽然有useMemo保护不受影响，但React仍然需要：

• 重新生成<div>、<input>、<textarea>、<ExpensiveList>的虚拟DOM节点
• 对整个组件树执行Diff
• 最终发现只有<input>的value属性变了

这个过程中，大部分计算都是「无用功」。更糟糕的是，如果开发者忘了写useMemo或React.memo，子组件会无条件重新渲染，性能直接崩盘。

React从v16开始引入Fiber架构，把渲染拆成可中断的单元，解决了「长时间阻塞主线程」的问题。但计算总量没有变——该做的Diff还是得做，该重新执行的树还是得执行。

2.2 一个数据说话的例子

让我们用实际数据看看虚拟DOM的开销。假设有一个包含10000个项目的列表，用户修改其中一个项目的文本：

// 基准测试：React虚拟DOM开销
function LargeList() {
  const [items, setItems] = useState(
    Array.from({ length: 10000 }, (_, i) => ({ id: i, text: `Item ${i}` }))
  )
  
  const updateItem = (id: number) => {
    const start = performance.now()
    setItems(prev => prev.map(item => 
      item.id === id ? { ...item, text: `Updated ${id}` } : item
    ))
    // React会：重新渲染整个列表 → Diff 10000个节点 → 更新1个DOM
    console.log(`Update took ${performance.now() - start}ms`)
  }
  
  return (
    <div>
      {items.map(item => (
        <div key={item.id} onClick={() => updateItem(item.id)}>
          {item.text}
        </div>
      ))}
    </div>
  )
}

在这个场景下，即使开启了React.memo，React仍然需要遍历这10000个key，逐个比对props的变化。在低端设备和复杂组件结构下，一次「小更新」可能带来几十毫秒的渲染开销——不远不近，恰好能被人感知到卡顿。

2.3 不可变数据的双刃剑

虚拟DOM必须搭配不可变数据才能高效工作。setState(newState)意味着「废弃旧树，构建新树」。这带来的问题：

// 不可变数据的「扩散效应」
const [user, setUser] = useState({
  name: 'Alice',
  settings: { theme: 'dark', fontSize: 14, ... }
})

// 哪怕只改字体大小，也必须创建整条链的新引用
setUser(prev => ({
  ...prev,
  settings: { ...prev.settings, fontSize: 16 }
}))

每次更新都要创建新的对象引用，这对JavaScript引擎的垃圾回收是一种压力。在大量高频更新的场景（动画、拖拽、实时数据流）下，GC暂停可能成为新的性能瓶颈。

三、Signal原理深度拆解：从依赖追踪到细粒度更新

理解了虚拟DOM的问题，Signal的解决方案就变得清晰了：与其每次跑完整Diff去猜「什么地方变了」，不如建立一个精确的依赖图，让状态变化直接通知到具体的DOM节点。

3.1 Signal的三要素

一个Signal系统由三个核心概念组成：

信号（Signal） → 计算（Computed） → 副作用（Effect）
    ↓                ↓                   ↓
  存储状态       派生状态            产生效果（DOM更新等）

Signal：响应式系统的「原子」。封装一个可变值，并维护一个订阅者列表。

Computed：基于一个或多个Signal的派生值。自动追踪依赖，只在依赖变化时重新计算。

Effect：当依赖的Signal或Computed变化时执行的副作用。在前端框架中，Effect的作用就是把值的变化同步到DOM。

3.2 从零实现一个Signal引擎

理解了概念后，让我们亲自动手实现一个最小但完整的Signal系统。这会让后续理解各大框架的实现少很多黑盒感。

// 最小完整Signal引擎实现（约200行）

type Subscriber = () => void

// ---- 全局依赖追踪上下文 ----
let currentEffect: (() => void) | null = null
const effectStack: (() => void)[] = []

function pushEffect(fn: () => void) {
  effectStack.push(fn)
  currentEffect = fn
}

function popEffect() {
  effectStack.pop()
  currentEffect = effectStack[effectStack.length - 1] ?? null
}

// ---- Signal ----
class Signal<T> {
  private value: T
  private subscribers: Set<Subscriber> = new Set()

  constructor(initialValue: T) {
    this.value = initialValue
  }

  // getter：读取值时，自动注册当前正在运行的Effect为订阅者
  get(): T {
    if (currentEffect) {
      this.subscribers.add(currentEffect)
    }
    return this.value
  }

  // setter：更新值时，通知所有订阅者
  set(newValue: T) {
    if (this.value !== newValue) {
      this.value = newValue
      // 遍历副本，避免在通知过程中修改Set
      const subs = [...this.subscribers]
      for (const sub of subs) {
        sub()
      }
    }
  }

  // 修改值的便捷方法（适用于对象等）
  update(fn: (prev: T) => T) {
    this.set(fn(this.value))
  }
}

// 创建Signal的工厂函数
function signal<T>(initialValue: T): Signal<T> {
  return new Signal(initialValue)
}

// ---- Computed（派生计算） ----
class Computed<T> {
  private value: T
  private dirty = true
  private effect: () => void
  private subscribers: Set<Subscriber> = new Set()

  constructor(compute: () => T) {
    this.value = compute()
    // Computed内部自己也是一个Effect（读取Signal时会被注册为订阅者）
    this.effect = () => {
      const oldValue = this.value
      const newValue = compute()
      if (oldValue !== newValue) {
        this.value = newValue
        this.dirty = true
        // 通知下游订阅者（Effect或其他Computed）
        const subs = [...this.subscribers]
        for (const sub of subs) {
          sub()
        }
      }
    }
  }

  get(): T {
    if (currentEffect) {
      this.subscribers.add(currentEffect)
    }
    // 惰性求值：只在被读取时检查是否需要重新计算
    if (this.dirty) {
      // 如果有分支未激活的依赖，需要重新订阅
      // 这里简化处理，实际实现需要更复杂的依赖管理
      this.dirty = false
    }
    return this.value
  }
}

function computed<T>(compute: () => T): Computed<T> {
  return new Computed(compute)
}

// ---- Effect ----
function effect(fn: () => void): () => void {
  const run = () => {
    pushEffect(run)
    fn()
    popEffect()
  }
  run()
  return () => {
    // 返回清理函数（实际实现需要清理注册到Signal的订阅）
    // 这里略
  }
}

// ---- 使用示例 ----
const firstName = signal('Alice')
const lastName = signal('Smith')

const fullName = computed(() => {
  return `${firstName.get()} ${lastName.get()}`
})

effect(() => {
  console.log(`Full name changed to: ${fullName.get()}`)
})
// 输出：Full name changed to: Alice Smith

firstName.set('Bob')
// 输出：Full name changed to: Bob Smith

lastName.set('Johnson')
// 输出：Full name changed to: Bob Johnson

这个实现虽然只有200行，但已经涵盖了Signal系统的全部核心机制：

1. 自动依赖追踪：通过全局currentEffect变量，在Signal.get()被调用时自动注册当前正在执行的Effect
2. 惰性计算：Computed只在被读取时才计算，未被读取的分支自动跳过
3. 级联传播：Signal → Computed → Effect的链式依赖自动管理
4. 脏检查：值未变化时不触发通知

3.3 真实实现中的关键优化

上面的最小实现虽然「能跑」，但离生产级还有几个关键差距。各框架的Signal实现都做了针对性的优化：

3.3.1 批量更新与调度

连续多次修改Signal不应该触发多次DOM更新：

// 批量更新的核心思想
let batchDepth = 0
const pendingEffects: Set<Subscriber> = new Set()

function batch(fn: () => void) {
  batchDepth++
  try {
    fn()
  } finally {
    batchDepth--
    if (batchDepth === 0) {
      // 只在最外层batch结束时执行所有pending的effect
      const effects = [...pendingEffects]
      pendingEffects.clear()
      for (const effect of effects) {
        effect()
      }
    }
  }
}

// 用法
batch(() => {
  signal1.set('a')
  signal2.set('b')
  signal3.set('c')
  // 只会在batch结束后执行一次DOM更新
})

Preact Signals和SolidJS都实现了类似的批量调度机制。Preact甚至将批量更新与React的unstable_batchedUpdates对齐，确保与React生态兼容。

3.3.2 避免重复计算

一个被多个Effect订阅的Computed，在依赖变化时应该只重新计算一次：

class ProductionComputed<T> {
  private value!: T
  private dirty = true
  private version = 0
  private subscribers: Set<Subscriber> = new Set()
  private sourceSubscriptions: Map<Signal<any> | Computed<any>, () => void> = new Map()

  constructor(private compute: () => T) {
    // 初始时订阅所有依赖
    this._evaluate()
  }

  private _evaluate() {
    // 在实际框架中，这里有更复杂的两阶段标记：
    // 第一轮：标记所有依赖为"可能已变"
    // 第二轮：只对标记过的依赖重新求值
    // 这里简化为直接执行compute
    const oldValue = this.value
    this.value = this.compute()
    this.version++
    this.dirty = false
  }

  get() {
    // 注册下游订阅
    if (currentEffect) {
      this.subscribers.add(currentEffect)
    }
    
    // 惰性重新求值
    if (this.dirty) {
      this._evaluate()
    }
    return this.value
  }
}

3.3.3 内存泄漏与自动清理

当组件卸载时，Signal系统必须自动清理所有订阅关系，否则就会造成内存泄漏和幽灵副作用：

// 自动清理的核心机制
class SubscriptionManager {
  private subscriptions: Map<Signal<any> | Computed<any>, () => void> = new Map()

  subscribe(source: Signal<any> | Computed<any>) {
    const unsubscribe = source._addSubscriber(this.onChange)
    this.subscriptions.set(source, unsubscribe)
  }

  cleanup() {
    for (const unsubscribe of this.subscriptions.values()) {
      unsubscribe()
    }
    this.subscriptions.clear()
  }
}

在Svelte 5中，组件的Effects生命周期与组件实例绑定。组件销毁时，所有Effect自动清理。SolidJS同理，createEffect创建的Effect会在组件卸载时自动清理。

四、五大框架Signal实现深度对比

4.1 Svelte 5 Runes：编译器级别的响应式革命

Svelte 5的Runes（符文）系统是对Svelte原有响应式系统的一次彻底重写。传统Svelte使用「编译时标记赋值语句」的方式实现响应式，而Runes用显式的$state、$derived、$effect标记，让响应式更加精确和可预测。

<!-- Svelte 5 Runes 示例 -->
<script lang="ts">
  let count = $state(0)
  let name = $state('')
  
  let greeting = $derived(`Hello, ${name}! Count is ${count}`)
  
  // 双击时输出日志
  $effect(() => {
    if (count > 0) {
      console.log(`Count doubled: ${count * 2}`)
    }
  })
  
  // 使用$effect追踪多次变化
  $effect(() => {
    // 这会创建一个「生命感知」的effect
    // 当页面处于隐藏状态时不会执行
    document.title = greeting
  })
  
  function increment() {
    count += 1
  }
</script>

<button onclick={increment}>
  Clicked {count} times
</button>
<p>{greeting}</p>

核心实现机制：Svelte 5将Runes编译为对__svelte_signal和__svelte_derived等内部函数的调用。这些函数返回Signal或Computed实例，然后通过__svelte_effect注册DOM更新副作用。编译器在编译阶段就能确定哪些变量是响应式的，从而生成最优化的更新代码。

关键创新：Svelte 5引入的$inspector（已改名为$state.frozen用于深度响应式对象）和对数组操作的细粒度追踪，让Signal模型在Svelte中达到了「编译器最优」的状态。

性能数据：在Js Framework Benchmark（2026版）中，Svelte 5在「大型列表CRUD」场景的帧率稳定在60fps，而同等数量的框架下React需要依赖react-window虚拟滚动才能不卡顿。

4.2 SolidJS：极致的Signal纯度

SolidJS把Signal作为第一性原理，没有引入任何其他响应式抽象。它的核心API只有三个：createSignal、createMemo、createEffect。

// SolidJS 组件
import { createSignal, createMemo, createEffect, For } from 'solid-js'

function TodoList() {
  const [todos, setTodos] = createSignal([
    { id: 1, text: 'Learn Signals', done: false },
    { id: 2, text: 'Build an app', done: false },
  ])
  const [filter, setFilter] = createSignal('all')
  
  // computed: 筛选后的todo列表
  const filteredTodos = createMemo(() => {
    const all = todos()
    switch (filter()) {
      case 'active': return all.filter(t => !t.done)
      case 'completed': return all.filter(t => t.done)
      default: return all
    }
  })
  
  // effect: 自动同步localStorage
  createEffect(() => {
    localStorage.setItem('todos', JSON.stringify(todos()))
  })
  
  // SolidJS的JSX不是「重新执行生成新VDOM」
  // 而是「一次执行注册细粒度更新」
  return (
    <div>
      <For each={filteredTodos()}>
        {(todo) => (
          <div>
            <input type="checkbox" checked={todo.done}
              onChange={() => setTodos(prev => prev.map(
                t => t.id === todo.id ? { ...t, done: !t.done } : t
              ))}
            />
            <span>{todo.text}</span>
          </div>
        )}
      </For>
    </div>
  )
}

核心实现机制：SolidJS的JSX编译器会将模板编译成「DOM创建代码」+「细粒度更新函数」的组合。组件函数只在首次执行时运行一次，后续状态变化不会重新执行组件，而是直接更新绑定了该Signal的DOM节点。

// 编译前（JSX）
<div>{count()}</div>

// 编译后（伪代码）
const el = document.createElement('div')
createEffect(() => { el.textContent = count() })

关键创新：SolidJS的createResource将异步数据获取与Signal整合，实现了基于Signal的Suspense：

// SolidJS 异步数据 + Signal
import { createResource, Suspense } from 'solid-js'

async function fetchUser(id: number) {
  const res = await fetch(`/api/users/${id}`)
  return res.json()
}

function UserProfile(props: { userId: Signal<number> }) {
  // createResource会自动追踪props.userId的变化
  // 当userId变化时自动重新请求
  const [user] = createResource(() => props.userId(), fetchUser)
  
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <div>{user()?.name}</div>
    </Suspense>
  )
}

4.3 Angular Signals：从RxJS到Signals的范式转变

Angular拥抱Signal是2026年最「breaking」的变革之一。Angular传统的Zone.js + ChangeDetection策略在很多场景下表现不错，但Zone.js「不知道什么变了」的盲盒式检测，在大组件树中带来了不必要的性能开销。

// Angular 20 使用Signal的组件
import { Component, signal, computed, effect } from '@angular/core'
import { toObservable } from '@angular/core/rxjs-interop'

@Component({
  selector: 'app-user',
  template: `
    <div>
      <input [value]="name()" (input)="onNameChange($event)" />
      <p>Welcome, {{ fullName() }}</p>
      <button (click)="reset()">Reset</button>
    </div>
  `,
  // 使用Signal后不需要Zone.js了
  changeDetection: ChangeDetectionStrategy.OnPush
})
export class UserComponent {
  private firstName = signal('John')
  private lastName = signal('Doe')
  
  // computed
  fullName = computed(() => `${this.firstName()} ${this.lastName()}`)
  
  // effect (Angular中effect在特定注入上下文中使用)
  private logEffect = effect(() => {
    console.log('Name changed:', this.fullName())
  })
  
  onNameChange(event: Event) {
    const value = (event.target as HTMLInputElement).value
    this.firstName.set(value)
  }
  
  reset() {
    this.firstName.set('John')
    this.lastName.set('Doe')
  }
}

核心实现机制：Angular的Signal实现非常「学院派」——它实现了完整的依赖图拓扑排序和「推-拉」（Push-Pull）混合传播算法。当Signal被修改时，会先「推」递地标记所有下游节点为脏（dirty），然后只在节点被get()时「拉」式重新计算。

Signal A 变化 → 标记 B 为脏 → 标记 C 为脏
                  ↓               ↓
              B 被读取时重新计算   C 被读取时重新计算

与RxJS的互操作：Angular提供了toObservable和toSignal两个函数，实现Signal与RxJS Observable的双向转换：

// Signal → Observable
import { toObservable } from '@angular/core/rxjs-interop'

const count = signal(0)
const count$ = toObservable(count)
count$.subscribe(v => console.log(`Count: ${v}`))

// Observable → Signal
import { toSignal } from '@angular/core/rxjs-interop'
import { interval } from 'rxjs'

const tick = toSignal(interval(1000), { initialValue: 0 })
effect(() => console.log(`Tick: ${tick()}`))

4.4 Preact Signals：无框架依赖的「即插即用」

Preact Signals最大的特点是框架无关。它是一个独立的库，可以在任何框架中使用——包括React：

// Preact Signals - 框架无关的核心API
import { signal, computed, effect } from '@preact/signals-core'

// 在任何JS环境都能用
const counter = signal(0)
const doubled = computed(() => counter.value * 2)

effect(() => {
  console.log(`Value: ${counter.value}, Double: ${doubled.value}`)
})

counter.value = 5
// 输出: Value: 5, Double: 10

在React中使用Preact Signals需要额外的适配层@preact/signals-react：

// 在React中使用Preact Signals
import { signal } from '@preact/signals-react'

const count = signal(0)

function Counter() {
  return (
    <div>
      {/* 在React中通过.value读取 */}
      <p>Count: {count.value}</p>
      <button onClick={() => count.value++}>+1</button>
    </div>
  )
}

核心实现机制：Preact Signals在处理React的集成时，巧妙地在React的fiber架构上「叠加」了一层细粒度更新。当Signal变化时，只会触发「读取了该Signal」的组件重新渲染，而不是整个组件树。

// Preact Signals React adapter的核心原理
// 在组件内部创建一个「代理组件」，只重新渲染Signal变化的部分
function useSignal<T>(initial: T): Signal<T> {
  const sig = useRef(signal(initial)).current
  const [, forceUpdate] = useReducer(x => x + 1, 0)
  
  useEffect(() => {
    // 订阅Signal变化，只更新当前组件
    return effect(() => {
      sig.value // 读取以建立依赖
      forceUpdate()
    })
  }, [sig])
  
  return sig
}

4.5 Vue 3：Proxy是另一种形式的Signal

严格来说，Vue 3的响应式系统不是「传统意义上的Signal」——它使用ES6 Proxy拦截对象的读取和写入操作。但两者在本质上是一致的：都是运行时的依赖追踪系统。

// Vue 3响应式（基于Proxy）
import { ref, computed, watchEffect } from 'vue'

const count = ref(0)
const doubled = computed(() => count.value * 2)

watchEffect(() => {
  console.log(`Count: ${count.value}, Double: ${doubled.value}`)
})

count.value++
// 输出: Count: 1, Double: 2

区别在于：Signal的依赖是在.get()或.value被调用时「手动注册」的；Vue 3 Proxy的依赖是在Proxy handler的get拦截器中「自动注册」的。效果等价，但Proxy方案的好处是开发者不需要显式调用.get()——obj.property就行了。坏处是Proxy无法拦截基本类型，所以Vue 3用ref()包装基本类型，内部使用getter/setter而非Proxy。

// Vue 3 ref的内部实现（简化）
function ref<T>(value: T) {
  const r = {
    _value: value,
    get value() {
      track(r, 'value')  // 依赖追踪
      return this._value
    },
    set value(newVal: T) {
      if (newVal !== this._value) {
        this._value = newVal
        trigger(r, 'value')  // 触发更新
      }
    }
  }
  return r
}

// Vue 3 reactive的内部实现（简化，使用Proxy）
function reactive<T extends object>(target: T): T {
  return new Proxy(target, {
    get(target, key, receiver) {
      track(target, key)  // 自动追踪
      return Reflect.get(target, key, receiver)
    },
    set(target, key, value, receiver) {
      const oldValue = Reflect.get(target, key, receiver)
      const result = Reflect.set(target, key, value, receiver)
      if (oldValue !== value) {
        trigger(target, key)  // 触发更新
      }
      return result
    }
  })
}

4.6 性能基准对比

2026年各框架在经典「大型表格更新」基准测试中的表现（以React为基准1.0，越低越好）：

数据来源：2026年Js Framework Benchmark（10000行表格，每行10列）

关键解读：

• Single cell update是Signal框架最大的优势——精准到「一个节点」的更新，不需要Diff
• 大表全量更新时，Signal的编译时优化让差距缩小，但仍显著优于VDOM
• Angular的Signal实现因为「推-拉」算法更复杂（拓扑排序+脏标记传播），比Svelte/Solid稍慢，但相比Zone.js已经是质的飞跃了

五、生产级实战：从Signal到完整应用

理论讲完了，来看一个实在的：用Signal模式构建一个「实时股票看板」应用。这个场景很有代表性——高频数据更新、多种数据聚合、大量DOM节点。

5.1 架构设计

Symbol Signal → 价格Signal → Computed: 涨跌幅
    ↓              ↓              ↓
WebSocket     Computed: MA5    Computed: 涨跌幅排行
    ↓              ↓              ↓
价格流          Computed: K线    Effect: 渲染表格

每个股票是一个独立的「响应式单元」，WebSocket推送的数据只更新对应的组件。

5.2 实现（使用SolidJS）

// 股票看板 - SolidJS实现
import { createSignal, createMemo, createEffect, For, Index } from 'solid-js'
import { createStore, produce } from 'solid-js/store'

// === 类型定义 ===
interface Stock {
  symbol: string
  name: string
  price: number
  prevClose: number
  volume: number
  timestamp: number
}

interface Kline {
  open: number
  high: number
  low: number
  close: number
  volume: number
  time: number
}

// === WebSocket数据流 ===
function createStockStream() {
  const [stocks, setStocks] = createStore<Record<string, Stock>>({})
  const [klines, setKlines] = createStore<Record<string, Kline[]>>({})
  
  const ws = new WebSocket('wss://api.example.com/stocks')
  
  ws.onmessage = (event) => {
    const data = JSON.parse(event.data)
    
    if (data.type === 'tick') {
      // 细粒度更新：只修改被点赞的股票
      setStocks(data.symbol, {
        price: data.price,
        volume: data.volume,
        timestamp: data.timestamp
      })
    } else if (data.type === 'kline') {
      setKlines(data.symbol, prev => [...prev.slice(-60), {
        open: data.open,
        high: data.high,
        low: data.low,
        close: data.close,
        volume: data.volume,
        time: data.time
      }])
    }
  }
  
  return { stocks, klines }
}

// === 计算属性 ===
function createStockDerived(stocks: Record<string, Stock>) {
  // 计算涨跌幅
  const changePercent = (symbol: string) => createMemo(() => {
    const stock = stocks[symbol]
    if (!stock) return 0
    return ((stock.price - stock.prevClose) / stock.prevClose * 100)
  })
  
  // 计算涨跌幅排行
  const ranking = createMemo(() => {
    return Object.values(stocks)
      .map(s => ({
        symbol: s.symbol,
        change: (s.price - s.prevClose) / s.prevClose
      }))
      .sort((a, b) => b.change - a.change)
      .slice(0, 10)
  })
  
  // 计算市场概况
  const marketOverview = createMemo(() => {
    const values = Object.values(stocks)
    const advancing = values.filter(s => s.price >= s.prevClose).length
    const declining = values.filter(s => s.price < s.prevClose).length
    const totalVolume = values.reduce((sum, s) => sum + s.volume, 0)
    
    return { advancing, declining, totalVolume }
  })
  
  return { changePercent, ranking, marketOverview }
}

// === 组件 ===
function StockRow(props: { stock: Stock }) {
  const change = createMemo(() => 
    ((props.stock.price - props.stock.prevClose) / props.stock.prevClose * 100).toFixed(2)
  )
  
  // 涨跌颜色 - 使用Signal风格的条件更新
  const color = createMemo(() => {
    const c = parseFloat(change())
    return c > 0 ? '#e74c3c' : c < 0 ? '#2ecc71' : '#999'
  })
  
  return (
    <tr style={{ color: color() }}>
      <td>{props.stock.symbol}</td>
      <td>{props.stock.name}</td>
      <td class="price">{props.stock.price.toFixed(2)}</td>
      <td class="change" style={{ color: color() }}>
        {change()}%
      </td>
      <td class="volume">{props.stock.volume.toLocaleString()}</td>
    </tr>
  )
}

// === 主应用 ===
function StockDashboard() {
  const { stocks, klines } = createStockStream()
  const { ranking, marketOverview } = createStockDerived(stocks as unknown as Record<string, Stock>)
  
  return (
    <div class="dashboard">
      {/* 市场概览卡 */}
      <div class="overview">
        <MarketTicker overview={marketOverview()} />
      </div>
      
      {/* 排行榜 */}
      <div class="ranking">
        <h3>涨幅榜 TOP 10</h3>
        <ol>
          <For each={ranking()}>
            {item => <li>{item.symbol}: +{(item.change * 100).toFixed(2)}%</li>}
          </For>
        </ol>
      </div>
      
      {/* 股票列表 - 1000行 */}
      <table class="stocks">
        <thead>
          <tr>
            <th>代码</th>
            <th>名称</th>
            <th>价格</th>
            <th>涨跌幅</th>
            <th>成交量</th>
          </tr>
        </thead>
        <tbody>
          <For each={Object.values(stocks)}>
            {(stock) => <StockRow stock={stock} />}
          </For>
        </tbody>
      </table>
    </div>
  )
}

5.3 性能对比：React vs SolidJS（真实WebSocket场景）

用Chrome DevTools Performance录制5分钟1000只股票的WebSocket实时推送：

React的问题不在于「慢」，而在于「每次更新都做太多无关的事」。即使所有组件都加了React.memo和useMemo，虚拟DOM的新建和Diff仍然有不可忽略的开销。

六、Signal的「陷阱」：不是银弹

Signal虽然强大，但并非没有代价。以下是实际项目中容易踩的坑：

6.1 循环依赖

Signal系统的自动依赖追踪在遇到循环依赖时会死循环：

// 循环依赖示例
const a = signal(1)
const b = computed(() => a.get() + 1)

// 糟糕！b的变化又会触发a的更新
// effect内部不应该修改Signal
effect(() => {
  a.set(b.get() + 1)  // 无限循环！
})

各框架的处理方式不同：SolidJS在检测到循环时会抛出Maximum update depth exceeded；Vue 3的watchEffect内部修改ref不会立即触发重新执行（因为微任务调度）；Preact Signals会限制嵌套更新层数（默认100层）。最佳实践：Effect中只读取Signal，不要写入Signal。

6.2 条件分支中的依赖丢失

这是Signal系统最常见的「bug模式」：条件分支导致依赖追踪不完整：

const show = signal(false)
const name = signal('Alice')

effect(() => {
  if (show.get()) {
    console.log(name.get())  // 只有当show为true时，name才会被追踪
  }
  // 依赖只有：show
  // 当show为false时修改name，effect不会重新执行
})

// 当show = false时修改name，不会触发effect
name.set('Bob')
// 当show变为true时，name.get()是'Bob'，但effect没被通知
// 因为依赖track时报的是上次运行时的依赖
// 上次show为false时，name的get()没被执行

解决方案：确保Effect中无条件读取所有可能用到的Signal，或者使用watchEffect之类的API明确声明依赖列表。Preact Signals和SolidJS都使用「重新订阅」策略——每次effect执行时清空旧依赖、重新收集新依赖，这可以部分解决条件分支问题，但无法完全消除「从未被读取过的分支」。

6.3 解构丢失

在Signal框架中，从Signal中解构变量会丢失响应性：

// 解构 - 丢失响应性 ❌
const [user] = createSignal({ name: 'Alice', age: 30 })
const { name, age } = user()  // 这里拿到的是普通值，不是Signal

// 正确做法：保持引用或使用解构API
const name = createMemo(() => user().name)  // ✅

这个陷阱在团队协作中特别容易触发，一旦有人习惯性地解构，bug就悄悄埋下了。

6.4 调试难度

虚拟DOM的调试相对直观——setState后看组件的渲染结果就行。Signal的依赖图是「隐式」的，调试时需要额外的工具支持：

// SolidJS的调试插件可以打印依赖图
import { debugSignal } from 'solid-devtools'

const count = createSignal(0)
debugSignal(count)  // 在DevTools中显示订阅关系

2026年现状：各框架的DevTool已经大幅改善了对Signal的调试支持。SolidJS DevTools、Svelte DevTools（v5支持Runes视图）、Angular DevTools（Signal面板）都可以可视化依赖图。但相比React DevTools的「组件树」视图，Signal的「依赖图」视图的学习曲线仍然稍高一些。

七、迁移策略：如何从React迁移到Signal框架

如果你的项目正在考虑从React迁移到Signal架构，有几种路径：

7.1 渐进式引入Preact Signals

不需要全部重写。在现有React项目中引入@preact/signals-react，先在深层子组件中使用Signal：

第1周：在UI库中试用
  UserDropdown → count信号 + 弹出状态信号
第2周：在数据密集型组件中推广
  大型表格、实时数据列表、复杂表单
第4周：全面评估
  对比核心场景性能，决定是否全量迁移

// 在React中「零风险」试用Signals
import { signal, computed } from '@preact/signals-react'

// 包装现有hook
function useStore<T>(key: string, initial: T) {
  const store = useMemo(() => signal(initial), [])
  
  useEffect(() => {
    const saved = localStorage.getItem(key)
    if (saved) store.value = JSON.parse(saved)
  }, [])
  
  useEffect(() => {
    const unsub = effect(() => {
      localStorage.setItem(key, JSON.stringify(store.value))
    })
    return unsub
  }, [])
  
  return store
}

7.2 SolidJS的全量迁移路线

对于新项目，SolidJS是「React语法 + Signal性能」的最佳平衡。如果你团队熟悉React，迁移路径相对平滑：

React语法 → SolidJS语法对照

useState → createSignal
useMemo  → createMemo
useEffect → createEffect
useCallback → 不需要（函数不会重复创建）
useRef  → 直接用let或createSignal
Context API → 用Signal跨组件（不需要Provider）

关键差异：SolidJS的JSX只在初始化时执行一次，这意味着：

// React：每次渲染都重新执行函数
function Card({ item }) {
  const style = { color: item.color }  // 每次重新创建对象
  return <div style={style}>{item.name}</div>
}

// SolidJS：函数只执行一次
function Card(props) {
  // ❌ 错误！style不会随props.color变化而更新
  const style = { color: props.item.color }
  return <div style={style}>{props.item.name}</div>
  
  // ✅ 正确：使用Signal响应式
  const style = createMemo(() => ({ color: props.item.color }))
  return <div style={style()}>{props.item.name}</div>
}

7.3 Svelte 5的「渐进式Runes」

Svelte 5兼容Svelte 4语法，可以在现有项目中分模块引入Runes：

<!-- 旧组件（Svelte 4语法）仍然可用 -->
<script>
  let count = 0
  $: doubled = count * 2
</script>

<!-- 新组件（Svelte 5 Runes） -->
<script>
  let count = $state(0)
  let doubled = $derived(count * 2)
</script>

7.4 Angular的「信号式」迁移

Angular从v17到v20逐步推进Signal，迁移路径经过精心设计：

Phase 1: 在独立组件中使用Signal
  → 替换@Component中的属性为signal()
Phase 2: 替换Zone.js检测策略
  → changeDetection: ChangeDetectionStrategy.OnPush
Phase 3: 移除Zone.js依赖
  → 在main.ts中使用provideNoopZone()
Phase 4: 全面Signal化
  → 替换RxJS Subject为signal，替换AsyncPipe为signal.管道

// Phase 1: 最简单的Signal替换
@Component({...})
export class UserComponent {
  // Before: Zone.js自动追踪
  name = 'Alice'

  // After: Signal显式管理
  name = signal('Alice')
  
  // 模板中使用name()而非name
}

八、未来展望：Signal会成为前端的新标准吗？

8.1 TC39 Signal Polyfill（2026进展）

2024年提出的TC39 Signal Proposal正在推进（当前Stage 1）。如果Signal成为JavaScript语言级的标准，意味着将来浏览器原生支持Signal：

// 未来的语言级Signal（TC39提议，2026年状态：Stage 1）
// 所有框架不再需要自实现Signal，直接用原生API

// 伪代码 - 原生Signal的用法
Signal.subtle.Watcher // 浏览器内置的副作用调度器

这会带来几个根本性变化：

• 框架间的Signal可以互操作
• 浏览器内部可以直接优化Signal的传播路径
• 跨框架的响应式数据共享成为可能

8.2 编译期Signal：Compatible with React Forget

React Compiler 1.0的思路本质上也是在「编译期推导出细粒度依赖」。React Compiler的输出结果——精确到变量级别的memoization——与Signal的方向是相同的，只是React选择了「编译器推导」而非「运行时追踪」。

// React Compiler 编译后的效果
function UserCard({ user }) {
  const name = user.name  // React Compiler会推断：只依赖user.name
  const avatar = user.avatar
  
  return <div>{name}</div>  
  // 当user.avatar变化时，name不会变，这个组件不会重新渲染
  // 因为编译器证明了：name只依赖user.name
}

但React Compiler不是运行时Signal——它生成的是「优化后的React代码」，底层仍然是组件级的虚拟DOM更新。它的「细粒度」是编译风控的，而非运行时的。

8.3 多框架互操作

2026年出现了一个有趣的趋势：框架中的Signal可以跨框架共享。例如，Preact Signals可以在SolidJS中使用，反之亦然（经过适配层）：

// 跨框架Signal共享（2026年可行方案）
import { signal } from '@preact/signals-core'
import { toSolidSignal } from 'signal-adapter'

// 在SolidJS组件中消费Preact Signal
const sharedCount = signal(0)

function SolidComponent() {
  const solidCount = toSolidSignal(sharedCount)
  
  return <div>{solidCount()}</div>
}

这种互操作性可能会催生「响应式统一层」——底层用标准Signals，上层对接不同框架的渲染器。

九、结语

2026年的前端响应式格局已经非常清晰：虚拟DOM的时代正在过去，Signal的时代正在到来。

这不是说React会消失——React的生态、工具链、第三方库积淀太深厚了，五年内仍会是使用率最高的框架。但在「数据密集型」「高频更新」「复杂交互」这类场景中，Signal方案的优势已经大到无法忽视了。

Signal的胜利不是「又一个框架」，而是一个更符合计算机底层规律的架构方式。发布-订阅模式、依赖图传播、惰性求值——这些都不是新概念，Signal只是把它们系统地应用到UI开发中，用精确的依赖管理取代暴力的全量Diff。

选择框架从来不是技术问题，而是工程权衡：

1. 你的应用类型是什么？数据密集型 → Signal框架；内容展示型 → 什么框架都行
2. 团队现有的技能储备是什么？不一定要「最先进」，要「最可控」
3. 你在2026年做的是新产品还是维护旧产品？新项目大胆用Signal，旧项目渐进式迁移

最后，无论你选择哪个框架，理解Signal的底层原理都会让你成为更好的前端工程师——因为响应式编程的范式，正在从前端蔓延到全栈，从UI层渗透到数据层，从客户端扩展到服务端。掌握了Signal，你就掌握了前端未来十年的核心技术。

参考资源

• SolidJS官方文档：createSignal vs useState
• Svelte 5 Runes RFC
• Angular Signals设计文档（angular.io/guide/signals）
• Preact Signals源码分析
• TC39 Signal Proposal（Stage 1）
• Js Framework Benchmark 2026 Edition
• Vue 3响应式源码解析

十、源码层对比：各框架Signal实现的核心差异

框架层面的API差异只是「面子」，真正重要的是「里子」——各框架在Signal的底层实现上做出了迥异的设计取舍。我们来扒开源码看看。

10.1 Svelte 5的「编译器优化派」

Svelte 5是「编译时最强」的代表。Runes在编译阶段完成大部分工作：

// Svelte 5 Runes编译过程（简化）

// 源码：
// let count = $state(0)
// let doubled = $derived(count * 2)
// $effect(() => { console.log(doubled) })

// 编译后（伪代码/Svelte内部IR）：
import { __svelte_signal, __svelte_derived, __svelte_effect } from 'svelte/internal'

let count = __svelte_signal(0)
let doubled = __svelte_derived(() => count.val * 2)
__svelte_effect(() => { console.log(doubled.val) })

Svelte编译器在「无运行时」和「部分运行时」之间找到了一个有趣的平衡点：

• 编译时分析模板，确定哪些变量是响应式的，哪些DOM节点依赖哪些变量
• 运行时Signal处理「运行时动态依赖」（比如条件分支中出现的Signal）
• 最终生成的代码只包含「必要」的运行时开销

编译器做了什么：

<!-- 输入 -->
<script>
  let count = $state(0)
  let items = $state([1, 2, 3])
</script>

<ul>
  {#each items as item}
    <li>{count} - {item}</li>
  {/each}
</ul>
<button onclick={() => count++}>+</button>

编译器分析得出：

• <li>{count} - {item}</li> 读取了 count 和 item
• count 变化 → 更新所有 <li> 的文本内容
• items 变化（增删元素） → 更新DOM结构（添加/移除<li>）
• item 中的某个元素值变化 → 只更新对应的DOM节点

编译后的代码大致为：

// 编译产物（极度简化）
function render(anchor) {
  let count = signal(0)
  let items = signal([1, 2, 3])

  // 模板生成的DOM创建代码
  const ul = document.createElement('ul')
  const button = document.createElement('button')
  button.textContent = '+'

  // 响应式模板更新
  const update = template((item) => html`
    <li>${count} - ${item}</li>
  `)
  
  // 自动订阅items变化，更新整个列表DOM
  effect(() => {
    update.each(ul, items.val)
  })

  button.onclick = () => count.val++
  // count变化：自动更新所有已渲染的<li>
  // 不需要调用任何"更新函数"
  // 因为Signal -> DOM的绑定在编译时已经建立了
}

Svelte 5编译时的独特优势：由于编译器知道所有模板中的Signal依赖，它可以「跳过」运行时的依赖重新收集步骤——这将每次Effect执行时的track开销降低到接近零。

10.2 SolidJS的「运行时细微派」

SolidJS看起来和Svelte很像（都抛弃虚拟DOM），但选择了一条更偏「运行时」的路径：

// SolidJS响应式核心（简化源码级）
// @solidjs/signals 中的核心实现

// 全局上下文（类似我们前面实现的currentEffect）
const globalContext: Owner | null = null

interface Owner {
  owned: Set<Owner>
  cleanups: Set<() => void>
  contexts: Map<string, any>
  sourceMap: Map<Signal<any>, number> // 依赖映射
}

// Signal的核心实现
export function createSignal<T>(value: T): [() => T, (v: T) => void] {
  const observers = new Set<(v: T) => void>()
  const sources = new Set<SignalNode>()
  
  function read(): T {
    // 依赖追踪：将当前执行的Observer注册到Signal
    const running = getRunningOwner()
    if (running) {
      observers.add(running)  // 这里running是一个Effect或者Memo
      // 反向注册：让Observer知道它依赖了哪些Signal
      running.sourceMap.set(sig as SignalNode, SignalNode.version)
    }
    return value
  }
  
  function write(next: T | ((prev: T) => T)): void {
    value = typeof next === 'function' ? (next as Function)(value) : next
    // 遍历副本并通知
    const toNotify = [...observers]
    for (const obs of toNotify) {
      if (obs.pure) {
        // pure observer（Memo类型）：标记为脏，惰性求值
        obs.dirty = true
        // 进一步传播
        propagate(obs)
      } else {
        // impure observer（Effect类型）：调度执行
        scheduler.enqueue(obs)
      }
    }
  }
  
  return [read, write]
}

SolidJS的关键设计决策：

1. Getter函数而非属性访问：SolidJS使用signal()而非signal.value。这使得依赖追踪可以「无标记」进行——任何在Effect中调用了getter的Signal都会被自动追踪。

2. 同步调度：Signal写入后，Effect默认同步执行。这避免了异步调度带来的「短暂不一致」问题，但代价是深度嵌套的更新链可能同步阻塞主线程。

3. No Proxy：SolidJS没有任何Proxy或Object.defineProperty的魔法。完全依赖函数调用的拦截。这使得SolidJS的Signal在和原生JavaScript互操作时更为透明——没有「隐式」的响应式，一切都是显式的函数调用。

10.3 Vue 3 Proxy的「隐式魔法派」

Vue 3的响应式系统是三者中「运行时魔法」最多的：

// Vue 3 响应式源码（简化的核心）

// 全局活跃Effect
let activeEffect: ReactiveEffect | null = null

// ref包装
export function ref<T>(value: T) {
  const r = {
    _isRef: true,
    get value() {
      track(r, TrackOpTypes.GET, 'value')
      return this._value
    },
    set value(newVal) {
      if (hasChanged(newVal, this._value)) {
        this._rawValue = newVal
        this._value = toReactive(newVal)
        trigger(r, TriggerOpTypes.SET, 'value')  // 触发依赖
      }
    }
  }
  return r
}

// Proxy的reactive
export function reactive<T extends object>(target: T): T {
  const proxy = new Proxy(target, {
    get(target, key, receiver) {
      track(target, TrackOpTypes.GET, key)  // 自动追踪
      const value = Reflect.get(target, key, receiver)
      // 深层响应式：如果属性值是对象，继续包装
      if (isObject(value)) {
        return reactive(value)
      }
      return value
    },
    set(target, key, value, receiver) {
      const oldValue = target[key as any]
      const result = Reflect.set(target, key, value, receiver)
      if (hasChanged(value, oldValue)) {
        trigger(target, TriggerOpTypes.SET, key)  // 触发更新
      }
      return result
    }
  })
  return proxy
}

Vue 3 Proxy方案的核心差异：

1. 隐式依赖：开发者不需要显式调用.value（reactive对象）。对于对象属性，访问obj.key就自动完成了依赖注册。这降低了心智负担，但也带来了「不知道什么时候触发了响应式」的模糊性。

2. 深层响应式：Vue 3的reactive默认深度包装所有嵌套对象。这意味着state.user.address.city这样的路径也能自动追踪。但这也意味着创建reactive对象时需要进行深层Proxy包装，对于大型深层对象，初始化成本比SolidJS/Svelte高（后者只追踪「被读取」的路径）。

3. Ref unwrapping：Vue 3在模板编译和watch中自动unwrap ref，让count在模板中可以直接用（无需count.value）。这对开发者友好，但增加了「运行时反射」的开销——Vue需在运行时检查每个值是否是ref。

性能权衡：Vue 3的Proxy方案在「开发效率」上最优——写起来最自然、不需要额外语法。但运行时的Proxy拦截有不可忽略的开销：每次属性访问都触发handler函数，在帧渲染时大量密集的属性访问（如渲染10000行的表格）下，Proxy的hook开销占总渲染时间的5%-15%。

10.4 Angular Signals的「学院派」

Angular的Signal实现最为「科班」——它实现了完整的「拉-推」算法：

// Angular Signals核心（简化）
// 来源：angular/packages/core/src/signals/src/

// 每个Signal有一个版本号（单调递增）
let globalVersion = 0

class Node {
  // 当前值版本
  version = 0
  // 被哪些节点消费了
  consuming: Set<Node> = new Set()
  // 我消费了哪些节点
  produced: Set<Node> = new Set()
}

class WritableSignal<T> extends Node {
  constructor(private value: T) { super() }
  
  set(newValue: T) {
    if (this.value !== newValue) {
      this.value = newValue
      this.version = ++globalVersion
      // 推模式：通知所有消费方「我变了」
      for (const consumer of this.consuming) {
        consumer.markDirty()
      }
    }
  }
  
  get(): T {
    // 注册到当前活跃的消费者
    registerConsumer(this)
    return this.value
  }
}

class ComputedNode<T> extends Node {
  private compute: () => T
  private isDirty = true
  
  get(): T {
    registerConsumer(this)
    
    // 拉模式：检查依赖是否比我的版本新
    if (this.isDirty) {
      this.recompute()
    }
    return this.value
  }
  
  private recompute() {
    // 推-拉混合：先问所有上游「你变了吗」
    let needRecompute = false
    for (const source of this.produced) {
      if ((source as ComputedNode).isDirty || 
          source.version > this.lastSourceVersion) {
        needRecompute = true
        break
      }
    }
    
    if (needRecompute) {
      this.value = this.compute()
      this.lastSourceVersion = globalVersion
      this.isDirty = false
      // 继续通知下游
      for (const consumer of this.consuming) {
        consumer.markDirty()
      }
    }
  }
}

Angular与其他框架的核心差异：

1. 严格的「推-拉」分离：

   • 推（Push）：Signal被修改时，标记所有下游节点为「可能脏」
   • 拉（Pull）：只有节点被.get()访问时，才实际检查是否需要重新计算
   • 优势：未被读取的分支永不计算（即使它是最上游Signal的依赖）
   • 代价：增加了「脏标记传播」的复杂度

2. 拓扑排序保证：Angular会使用拓扑排序确保Effect的执行顺序与依赖关系一致——如果A → B → C，则A先执行，然后B，最后C。这在嵌套的Signal链中确保了「结果一致性」。

3. 与Zone.js的集成：Angular的Signal设计考虑了与Zone.js的共存。当在Zone.js包装的异步操作中修改Signal时，自动触发变更检测。这与「纯Signal」框架的设计思路不同——Angular的目标是平滑迁移，而非一刀切。

10.5 各框架实现模式的总结对比

十一、生产级迁移实战：React → SolidJS

11.1 迁移路径

对于新项目，SolidJS是「React语法 + Signal性能」的最佳平衡。核心API映射：

11.2 关键差异

SolidJS的JSX只在初始化时执行一次，这意味着：

// ❌ 错误！style不会随props变化更新
function Card(props) {
  const style = { color: props.item.color }
  return <div style={style}>{props.item.name}</div>
}

// ✅ 正确：使用createMemo保持响应式
function Card(props) {
  const style = createMemo(() => ({ color: props.item.color }))
  return <div style={style()}>{props.item.name}</div>
}

11.3 迁移后性能对比（真实项目）

某电商订单管理系统从React 18 + Redux迁移到SolidJS后的数据：

核心收益：团队不再需要「性能优化阶段」，Signal的细粒度更新「默认就是最优的」。

十二、性能优化深度指南：将Signal的潜能榨干

即使Signal提供了「默认高性能」，仍然有一些优化技巧能让你的应用飞起来。

12.1 拆分Signal粒度

一条黄金法则：Signal的粒度越细，更新越高效。

// ❌ 粗粒度：整个用户对象用一个Signal
const user = createSignal({ name: 'Alice', avatar: 'a.jpg', bio: '...' })
// 改bio的时候，name和avatar的组件也会重新渲染

// ✅ 细粒度：每个字段独立Signal
const userName = createSignal('Alice')
const userAvatar = createSignal('a.jpg')
const userBio = createSignal('...')
// 改bio的时候，只有bio的DOM节点更新

但这个也有一个「度」。过于细碎的Signal会增加内存开销和管理复杂度。实践中，按「一起变化的频率」分组：

// 合理粒度的信号分组
// 「一起变化」的数据放一个Signal
const userProfile = createSignal({ name: 'Alice', avatar: 'a.jpg' })
// 「单独变化」的数据放独立Signal
const userBio = createSignal('...')
const userStatus = createSignal('online')

12.2 使用untrack显式断开依赖

有些场景下，你希望读取一个Signal的值但不建立依赖关系：

import { untrack } from 'solid-js'

const count = createSignal(0)
const savedCount = createSignal(0)

createEffect(() => {
  // 读取count并建立依赖
  console.log(`Current: ${count()}`)
  
  // 读取savedCount但不建立依赖
  // savedCount变化不会触发这个Effect重新执行
  const lastSaved = untrack(() => savedCount())
  console.log(`Last saved: ${lastSaved}`)
})

untrack在日志记录、一次性初始化、避免反向依赖等场景非常有用。

12.3 使用createResource处理异步

SolidJS的createResource是专为「异步数据」设计的Signal集成：

const [userId, setUserId] = createSignal(1)

// 自动追踪userId的变化，变化时重新fetch
const [user] = createResource(userId, async (id) => {
  const res = await fetch(`/api/users/${id}`)
  return res.json()
})

// 可选的refetch机制
const [user, { mutate, refetch }] = createResource(fetchUser)

// 手动设置乐观更新
mutate({ name: '暂时的新名字' })  // 不触发fetch，直接设置缓存

与React Query的对比：

• React Query的核心是「缓存+失效」模式
• SolidJS Resource的核心是「数据=Signal+异步」模式
• Resource更轻量（不需要Cache Provider），但也没有React Query那么丰富的缓存策略

12.4 批量更新陷阱

虽然Signal的设计让「不需要主动批量」——甚至鼓励「原子性」，但有些场景需要显式控制：

// 紧耦合的更新：两个Signal必须在「同一帧」完成
function updateUserAndNotify(name: string, bio: string) {
  // 默认情况下，每次set都会立即触发Effect
  setName(name)  // → Effect执行（但此时bio还没更新，导致中间状态不一致）
  setBio(bio)    // → Effect再次执行（此时name和bio都更新了）
  
  // 中间态导致Effect执行了两次
  // 如果Effect中有网络请求，会发送两次请求！
}

// 使用batch打包
import { batch } from 'solid-js'

function updateUserAndNotify(name: string, bio: string) {
  batch(() => {
    setName(name)
    setBio(bio)
  })
  // batch结束后，Effect只执行一次
  // name和bio都是最终值，没有中间态
}

12.5 避免在Effect中创建大量闭包

Effects中创建闭包会形成隐式的「额外依赖」：

// ❌ 不推荐：effect闭包太复杂
createEffect(() => {
  const items = data()
  // 这里创建大量循环闭包
  items.forEach(item => {
    someStore.push({ ...item, timestamp: Date.now() })
  })
})

// ✅ 推荐：把计算逻辑抽到memo中
const processedItems = createMemo(() => {
  const items = data()
  return items.map(item => ({ ...item, timestamp: Date.now() }))
})

createEffect(() => {
  someStore.push(...processedItems())
})

Memo的输出是稳定的（只要依赖不变，返回相同引用），而Effect内部直接处理会每次重建新对象。

十三、未来展望

TC39 Signal标准化

2026年TC39 Signal Proposal处于Stage 1。如果顺利，2027-2028年可能进入Stage 3，浏览器原生支持Signal：

// 未来的JavaScript原生Signal
const count = new Signal.State(0)
const doubled = new Signal.Computed(() => count.get() * 2)

原生Signal的优势：零框架开销（浏览器直接实现依赖追踪）、跨框架互操作、内存效率更高。

编译时Signal

Svelte已在探索「编译时优化」，完全零运行时的Signal需要更多编译器工程突破。服务端Signal（数据变化增量推送到客户端）也是值得关注的方向。

十四、结语

2026年，Signal已经从实验性模式变成前端主流范式。这场革命的本质是：从「我猜你可能变了」到「我知道你变了」。

虚拟DOM用计算资源换开发体验，Signal用系统设计换运行效率。在2026年移动设备占主导的硬件环境下，选择「更少计算」是更可持续的架构方向。

但Signal不是万能药：内容展示型应用优势不明显；深度绑定React生态的团队迁移成本可能超过收益；招聘角度React依然最容易。

选择框架是情境依赖的。但理解Signal原理，无论用什么框架，都会让你成为更好的工程师。响应式编程的范式正在从前端蔓延到全栈，从UI层渗透到数据层——Signal不只是框架的Signal，而是你对高性能Web应用理解的Signal。