前端框架渲染模型深度拆解：从 Virtual DOM 到 Signals，React 19、Vue、Svelte 5 与 SolidJS 的 2026 终极对决

如果你在 2026 年还在用「哪个框架更火」来选型，那你已经输在了起跑线。
这一代框架之争，表面上是语法和生态的比拼，底层却是两种渲染哲学的正面交锋：
一边是「组件函数重执行 + 虚拟 DOM Diff」的运行时代价，另一边是「信号驱动 + 编译时直出」的细粒度更新。
本文用一个贯穿全程的实战案例，把 React 19、Vue 3/4、Svelte 5、SolidJS 这四套响应式引擎扒开看个底朝天。

背景介绍：为什么「框架选型」在 2026 年变得反直觉

五年前，前端圈选型的逻辑很朴素：谁生态大、谁招人容易、谁踩坑有 Stack Overflow 答案，就选谁。React 几乎是不假思索的默认答案。

但到了 2026 年，这个逻辑开始失效。原因有三：

第一，性能瓶颈从「能不能跑」变成了「高频更新卡不卡」。
当你的页面里塞满了实时表格、协作文档、股票行情、AI 流式输出，状态每秒变化几十次时，框架的「更新粒度」直接决定了用户体验。React 的「整棵组件子树重渲染」在这个场景下会吃大亏，而细粒度框架几乎无感。

第二，编译技术成熟了。
Svelte 证明了「把响应式逻辑在编译期算死，运行时只留裸 DOM 操作」这条路不仅走得通，而且产物更小、更快。Vue 的 Vapor Mode、Solid 的编译期 Signal 都是同一思路的延伸。编译时优化，已经从「锦上添花」变成了「性能主战场」。

第三，Signals 正在成为跨框架的事实标准。
Angular 有了 Signals，Preact 有了 Signals，甚至 React 社区内部关于 Signals 的讨论也从未停过（虽然官方路线是 RSC + 编译器的「自动 memo」）。一个共识正在形成：细粒度响应式是未来，虚拟 DOM 只是历史过渡。

但共识归共识，四套框架的实现天差地别。理解它们的差异，比背 API 重要一百倍——因为当你遇到性能问题、调试陷阱、迁移成本时，决定你生死的是底层模型，不是文档示例。

本文不会告诉你「无脑选 X」，而是给你一套从模型到代码、从性能到选型的完整认知框架，让你在任何业务场景下都能做出有依据的判断。

核心概念：先搞懂「响应式」到底在解决什么问题

抛开框架名字，所有前端框架要解决的其实是同一个问题：

当状态（state）变化时，如何高效、正确、自动地把变化同步到视图（view）？

这个问题的解法，决定了框架的一切特性。我们把它拆成三个关键维度：

1. 更新粒度：组件级 vs 节点级

• 组件级（Component-level）：状态变了，框架重新执行整个组件函数，重新生成一份「虚拟描述」，再和旧的对比，找出变化的 DOM 节点。React 是典型代表。
• 节点级（Fine-grained / 细粒度）：状态变了，框架直接知道「这个 <span> 依赖这个状态」，只更新那一个文本节点，不重跑任何组件函数。Solid、Svelte、Vue 的响应式核心都是这个思路。

粒度差异带来的结果非常直观：一个计数器组件里，如果只有数字在变，组件级框架会把整个组件重算一遍（即使 99% 的 DOM 没变），而细粒度框架只改那一个数字。

2. 追踪时机：Pull（拉取） vs Push（推送）

• Pull（惰性/拉取）：框架在「渲染时」才知道谁依赖了谁。比如 React 每次重渲染时重新执行组件，重新读 state，才知道这次谁用到了新值。
• Push（主动/推送）：框架在「定义时」就建立好了依赖图（dependency graph）。state 一变，立刻沿着图通知下游节点。Solid 的 Signal 就是典型 Push 模型。

Push 模型的优势是「零扫描开销」——不需要重新执行组件去发现依赖，依赖关系在编译/初始化时就钉死了。

3. 优化时机：Compile-time（编译时） vs Runtime（运行时）

• 运行时优化：框架在浏览器里跑 diff、做比对、做 memo 决策。React 的虚拟 DOM Diff 全程在运行时。
• 编译时优化：框架在 build 阶段就把「哪些是静态的、哪些是动态的、谁依赖谁」算清楚，生成几乎无运行时的高效代码。Svelte 是极端代表，Vue 的 Patch Flag 是温和代表。

这三个维度组合，就画出了四套框架的坐标：

记住这张表，后面所有代码和性能分析都围着它转。

架构分析：四大框架的引擎是怎么转的

React 19：虚拟 DOM 的最后堡垒，也是自动 memo 的新起点

React 的核心心智模型一句话：UI 是 state 的纯函数，UI = f(state)。

当你调用 setState，React 不会去「找谁用了这个 state」，而是标记组件「脏了」，然后在合适的时机（同步或并发中断）重新执行整个组件函数，生成新的 React 元素树，再和上一棵做 Diff，把差异 Patch 到真实 DOM。

function Counter() {
  const [count, setCount] = useState(0);
  // 每次 count 变化，整个 Counter 函数都会重新执行
  // 即使 <h1> 是静态的，它也会在虚拟树里被重新创建一次（再被 diff 判定为不变）
  return (
    <div>
      <h1>静态标题</h1>
      <p>当前计数：{count}</p>
      <button onClick={() => setCount(c => c + 1)}>+1</button>
    </div>
  );
}

代价在哪？ 组件函数重执行本身有成本：重新创建闭包、重新创建事件处理函数、重新创建子元素对象。当组件树很深、列表很长，一次 setState 可能触发成百上千个函数调用。

React 19 的两大应对：

1. 并发特性（Concurrent Rendering）：useTransition、useDeferredValue 让低优先级更新可以被高优先级更新打断，避免输入框卡顿。
2. React Compiler（React 编译器）：这是 2025 年后最关键的变革。它自动帮你插入 useMemo / useCallback / React.memo，不再需要手写。本质上，React 在用编译时手段逼近细粒度框架的效果——但它是「自动加 memo」而不是「从根上消灭重渲染」，所以粒度仍然是组件级。

// React Compiler 开启后，下面这段代码会被自动记忆化
// 无需手写 useMemo，编译器分析依赖后自动包裹
function ExpensiveList({ items, query }) {
  const filtered = items.filter(i => i.name.includes(query));
  return <ul>{filtered.map(i => <li key={i.id}>{i.name}</li>)}</ul>;
}

RSC（React Server Components）的意义：React 19 把「组件」分成了服务端组件和客户端组件。服务端组件在服务器渲染、不进入客户端 bundle、不参与客户端重渲染。这其实是在绕开客户端重渲染问题——把不常变的部分直接踢出客户端响应式系统。

Vue 3/4：Proxy 响应式 + 编译时 Patch Flag 的「混合派」

Vue 的响应式核心是 Proxy。当你用 ref() 或 reactive() 包裹数据时，Vue 返回一个 Proxy，所有 .get 都会被「依赖收集」，所有 .set 都会触发「派发更新」。

import { ref, computed, watchEffect } from 'vue';

const count = ref(0);
// count.value 被读取时，当前活跃的副作用（组件渲染 effect）会被收集为依赖
const double = computed(() => count.value * 2);
// watchEffect 立即执行一次，并在读取到的响应式数据变化时重新执行
watchEffect(() => {
  console.log(`count 变成 ${count.value}，double 是 ${double.value}`);
});

count.value = 5; // 自动触发 watchEffect，输出新值

Vue 的聪明之处在于它是「组件级 + 组件内细粒度」的混合体：

• 组件是响应式边界。状态变化先触发组件级更新（进入该组件的更新队列）。
• 但组件内部的 DOM 更新是细粒度的：Vue 在编译阶段给每个动态绑定打上 Patch Flag（比如 TEXT、CLASS、PROPS），运行时只更新带 Flag 的部分，静态节点直接跳过。

<template>
  <!-- 编译后：静态的 <h1> 不带 Patch Flag，永远跳过更新 -->
  <h1>静态标题</h1>
  <!-- 动态的 {{ count }} 被打上 TEXT Patch Flag -->
  <p>{{ count }}</p>
  <!-- :class 被打上 CLASS Patch Flag -->
  <button :class="{ active: count > 0 }" @click="count++">+1</button>
</template>

<script setup>
import { ref } from 'vue';
const count = ref(0);
</script>

Vue 4 / Vapor Mode（蒸汽模式）：这是 Vue 面向 2026 的关键演进。Vapor Mode 借鉴 Svelte，把组件编译成不带虚拟 DOM 的命令式代码，响应式直接绑定到具体 DOM 节点，进一步消除运行时 diff 开销。可以把它理解为「Vue 在保留模板语法的同时，悄悄走向了 Solid 的细粒度世界」。

Svelte 5：把响应式「编译死」的极端派

Svelte 的理念最激进：运行时几乎没有响应式系统，响应式全在编译期完成。

Svelte 5 引入了 Runes（符文）语法，用 $state、$derived、$effect 显式声明响应式：

<script>
  let count = $state(0);              // 声明响应式状态
  let double = $derived(count * 2);   // 派生状态，自动追踪依赖

  $effect(() => {
    console.log(`count=${count}, double=${double}`); // 自动追踪 count/double
  });
</script>

<h1>静态标题</h1>
<p>{count}</p>
<button onclick={() => count++}>+1</button>

关键差异：编译后，count 不是一个「对象」，而是一组 getter/setter 函数；{count} 这个插值被编译成「直接 textContent = count 的命令式语句」。换句话说，Svelte 没有虚拟 DOM，没有 diff，没有运行时依赖追踪——它把「谁依赖谁」在 build 时就硬编码成了赋值语句。

这也是为什么 Svelte 应用的运行时体积通常最小、首屏最快。但代价是：它的「响应式」是编译器的魔法，调试时你看不到一个清晰的运行时依赖图，只能相信编译器。

SolidJS：细粒度 Signal + JSX 的「最纯粹派」

Solid 和 React 长得很像（都用 JSX、都写「组件函数」），但行为截然相反。Solid 的灵魂一句话：组件函数只执行一次，之后永远不再重跑；状态变化直接更新 DOM。

import { createSignal, createMemo, createEffect, createResource } from 'solid-js';

function Counter() {
  const [count, setCount] = createSignal(0);
  const double = createMemo(() => count() * 2); // 记忆化派生

  createEffect(() => {
    console.log(`count=${count()}, double=${double()}`);
  });

  return (
    <div>
      <h1>静态标题</h1>
      {/* count() 读取时建立依赖：这个 <p> 的文本直接绑定到 count */}
      <p>{count()}</p>
      <button onClick={() => setCount(c => c + 1)}>+1</button>
    </div>
  );
}
// 注意：Counter 函数体只执行一遍！后续 count 变化不会重跑 Counter

Solid 的响应式是纯 Push 模型：

• createSignal 返回一个 [getter, setter]。getter 被调用时（在 effect/render 上下文中），会把自己注册为这个 Signal 的依赖。
• setter 被调用时，立刻通知所有依赖它的订阅者，精确更新绑定的 DOM 节点或重新执行对应 effect。

没有虚拟 DOM，没有 diff，没有组件重渲染。 它和 Svelte 殊途同归（都是细粒度 + 编译时），区别是 Svelte 用模板 + Runes，Solid 用 JSX + Signal API，心智模型更接近 React 老手。

代码实战：同一个应用，四种写法

为了让你直观感受差异，我们用一个统一的实战案例贯穿四套框架：一个简单的「任务看板 + 实时统计面板」，包含：

1. 一个计数器（点击 +1）
2. 一个派生值（count 是否为偶数）
3. 一个任务列表（可添加、可删除）
4. 一个异步数据加载（模拟 fetch 用户列表，带 loading 态）

React 19 版本

import { useState, useMemo, useTransition, useEffect } from 'react';

function Dashboard() {
  const [count, setCount] = useState(0);
  const [tasks, setTasks] = useState([]);
  const [users, setUsers] = useState([]);
  const [loading, setLoading] = useState(false);
  const [isPending, startTransition] = useTransition();

  // 派生值：用 useMemo 避免每次重渲染都重算（或交给 React Compiler 自动处理）
  const isEven = useMemo(() => count % 2 === 0, [count]);

  useEffect(() => {
    let cancelled = false;
    setLoading(true);
    fetch('/api/users')
      .then(r => r.json())
      .then(data => { if (!cancelled) setUsers(data); })
      .finally(() => { if (!cancelled) setLoading(false); });
    return () => { cancelled = true; }; // 防止卸载后 setState
  }, []);

  const addTask = (text) =>
    startTransition(() => setTasks(t => [...t, { id: Date.now(), text }]));

  const removeTask = (id) =>
    startTransition(() => setTasks(t => t.filter(x => x.id !== id)));

  return (
    <div>
      <h1>任务看板（React 19）</h1>
      <p>计数：{count} {isEven ? '（偶数）' : '（奇数）'}</p>
      <button onClick={() => setCount(c => c + 1)}>+1</button>

      <input
        placeholder="输入任务"
        onKeyDown={e => { if (e.key === 'Enter') { addTask(e.target.value); e.target.value=''; } }}
      />
      <ul>
        {tasks.map(t => (
          <li key={t.id}>{t.text} <button onClick={() => removeTask(t.id)}>×</button></li>
        ))}
      </ul>

      <h2>用户列表</h2>
      {loading ? <p>加载中…</p> : (
        <ul>{users.map(u => <li key={u.id}>{u.name}</li>)}</ul>
      )}
      {isPending && <p>更新中…</p>}
    </div>
  );
}

注意点：每次 count 变化，整个 Dashboard 重执行；列表渲染、用户列表也会跟着重新走一遍虚拟树（尽管内容没变）。useMemo 和 useTransition 是为了缓解这种重渲染的代价。

Vue 3 版本

<template>
  <div>
    <h1>任务看板（Vue 3）</h1>
    <p>计数：{{ count }} {{ isEven ? '（偶数）' : '（奇数）' }}</p>
    <button @click="count++">+1</button>

    <input v-model="draft" @keydown.enter="addTask" placeholder="输入任务" />
    <ul>
      <li v-for="t in tasks" :key="t.id">
        {{ t.text }} <button @click="removeTask(t.id)">×</button>
      </li>
    </ul>

    <h2>用户列表</h2>
    <p v-if="loading">加载中…</p>
    <ul v-else>
      <li v-for="u in users" :key="u.id">{{ u.name }}</li>
    </ul>
  </div>
</template>

<script setup>
import { ref, computed, onMounted } from 'vue';

const count = ref(0);
const tasks = ref([]);
const users = ref([]);
const loading = ref(false);
const draft = ref('');

// computed 自动追踪 count，count 变才重算
const isEven = computed(() => count.value % 2 === 0);

function addTask() {
  if (!draft.value.trim()) return;
  tasks.value.push({ id: Date.now(), text: draft.value });
  draft.value = '';
}
function removeTask(id) {
  tasks.value = tasks.value.filter(t => t.id !== id);
}

onMounted(async () => {
  loading.value = true;
  try {
    const res = await fetch('/api/users');
    users.value = await res.json();
  } finally {
    loading.value = false;
  }
});
</script>

注意点：count 变化只触发带 TEXT Patch Flag 的 <p> 更新，列表 <ul> 完全不碰。computed 是细粒度的，只有 count 变才重算 isEven。这就是 Vue「组件边界 + 内部细粒度」的体感。

Svelte 5 版本

<script>
  let count = $state(0);
  let tasks = $state([]);
  let users = $state([]);
  let loading = $state(false);
  let draft = $state('');

  const isEven = $derived(count % 2 === 0);

  function addTask() {
    if (!draft.trim()) return;
    tasks.push({ id: Date.now(), text: draft });
    draft = '';
  }
  function removeTask(id) {
    tasks = tasks.filter(t => t.id !== id);
  }

  $effect(() => {
    loading = true;
    fetch('/api/users')
      .then(r => r.json())
      .then(data => users = data)
      .finally(() => loading = false);
  }); // 仅初次运行（无响应式依赖被读取）
</script>

<h1>任务看板（Svelte 5）</h1>
<p>计数：{count} {isEven ? '（偶数）' : '（奇数）'}</p>
<button onclick={() => count++}>+1</button>

<input bind:value={draft} onkeydown={(e) => e.key === 'Enter' && addTask()} placeholder="输入任务" />
<ul>
  {#each tasks as t (t.id)}
    <li>{t.text} <button onclick={() => removeTask(t.id)}>×</button></li>
  {/each}
</ul>

<h2>用户列表</h2>
{#if loading}
  <p>加载中…</p>
{:else}
  <ul>{#each users as u (u.id)}<li>{u.name}</li>{/each}</ul>
{/if}

注意点：{count} 被编译成直接赋值 p.textContent = count 的命令式代码。$derived 编译期就绑定了依赖。整个组件没有虚拟 DOM——count++ 那一刻，只有那个 <p> 的文本节点变了。

SolidJS 版本

import { createSignal, createMemo, createResource, For } from 'solid-js';

function Dashboard() {
  const [count, setCount] = createSignal(0);
  const [tasks, setTasks] = createSignal([]);
  const [draft, setDraft] = createSignal('');
  const isEven = createMemo(() => count() % 2 === 0);

  // createResource 内置 loading 态与异步管理
  const [users] = createResource(async () => {
    const res = await fetch('/api/users');
    return res.json();
  });

  const addTask = () => {
    if (!draft().trim()) return;
    setTasks(t => [...t, { id: Date.now(), text: draft() }]);
    setDraft('');
  };
  const removeTask = (id) =>
    setTasks(t => t.filter(x => x.id !== id));

  return (
    <div>
      <h1>任务看板（SolidJS）</h1>
      <p>计数：{count()} {isEven() ? '（偶数）' : '（奇数）'}</p>
      <button onClick={() => setCount(c => c + 1)}>+1</button>

      <input
        value={draft()}
        onInput={e => setDraft(e.currentTarget.value)}
        onKeyDown={e => e.key === 'Enter' && addTask()}
        placeholder="输入任务"
      />
      <ul>
        <For each={tasks()}>{(t) =>
          <li>{t.text} <button onClick={() => removeTask(t.id)}>×</button></li>
        }</For>
      </ul>

      <h2>用户列表</h2>
      {users.loading ? <p>加载中…</p> : (
        <ul><For each={users()}>{(u) => <li>{u.name}</li>}</For></ul>
      )}
    </div>
  );
}

注意点：Dashboard 函数体只跑一次。{count()} 在 JSX 编译后变成「订阅 count 的 text 节点」。<For> 是 Solid 的高性能列表原语，它做细粒度 keyed 复用，增删一项不会重渲染整个列表（对比 React 的 map 仍走虚拟 diff）。

四种写法的体感对比

性能优化：基准、陷阱与实测方法

先看基准结论（JS Framework Benchmark 口径）

业界公认的 krausest/js-framework-benchmark 持续显示：在「行更新」「行替换」「部分更新」这类高频细粒度操作上，Solid、Svelte 比 React 快一个数量级；React 在「创建大量行」上也不占优。原因正是更新粒度——React 必须重渲染组件再 Diff，其他三者直达 DOM。

但基准不等于你的业务。React 在「整页低频切换」场景下完全够用，而且生态、招聘、稳定性优势巨大。性能优化的第一原则：先测量，再优化，别盲从基准。

各框架的高频坑与对策

React 19 的性能陷阱

• 大列表 key 用 index → 错位更新。务必用稳定 id。
• 把内联对象/函数当 prop → 子组件无谓重渲染（React Compiler 能缓解，但手写 memo 仍必要）。
• Context 值变化导致所有消费者重渲染。解法：useContextSelector、拆 Context、或把高频值移出 Context。
• 用 useDeferredValue / useTransition 把非紧急更新降级，保证输入流畅。

Vue 3 的性能陷阱

• 在 v-for 里用复杂 computed 且没缓存 → 每次渲染重算。
• reactive 大对象深层监听开销。解法：shallowRef / shallowReactive 配合手动 trigger。
• 过度 watch 监听整个对象 → 用 watch(() => obj.field, ...) 精确监听。
• 静态内容没被编译提升（动态条件包裹） → 用 v-once 或拆组件。

Svelte 5 的性能陷阱

• $effect 里读了不该读的响应式值 → 触发意外重算。保持 effect 依赖最小。
• 把 $state 数组直接 push 在跨组件共享时需注意响应式传播边界。
• 编译产物虽小，但大量 each 块仍要合理 keyed。

SolidJS 的性能陷阱

• $effect 里创建新订阅不清理 → 内存泄漏。用 onCleanup。
• 把一个 createStore 的巨大对象整体传给子组件 → 拆 store 分层。
• 在 JSX 里写 getSignal() + 1 这种表达式每次都会重新订阅 → 提取成 createMemo。

自己跑基准的最小方法

别只看别人跑的图。给你一个 10 行就能自测的通用思路（以「每秒点击 +1 十万次，测主线程占用」为例）：

// 伪代码：测量一次状态更新触发的 JS 工作量
const start = performance.now();
for (let i = 0; i < 100000; i++) setCount(c => c + 1);
// 注意：React 这类框架会把更新 batch，需要 flush 后再测
requestAnimationFrame(() => {
  console.log('更新 10 万次耗时：', performance.now() - start, 'ms');
});

更严谨的做法是用 Chrome DevTools 的 Performance 面板录制一次交互，看「Scripting」时间都花在了 reconcile（React）还是裸 DOM 赋值（Solid/Svelte）上。一眼就能看出瓶颈在哪。

总结展望：2026 年到底该选谁

把前面的分析收敛成一张选型决策表：

三个 2026 年的确定趋势

1. Signals 成为通用词汇。 不管你用不用 Solid，理解「Signal / 细粒度订阅图」都会成为前端基本功。它正在从「Solid 的专利」变成「全行业的底层语言」。

2. 编译时压倒运行时。 Svelte 证明了编译时响应式的可行性，Vue Vapor、React Compiler 都在向「把工作从浏览器搬到构建期」靠拢。未来框架的竞争，越来越是编译器的竞争。

3. RSC / SSR / 流式渲染融合。 「客户端重渲染」这个问题，另一个解法是「别让它发生」——把不常变的部分放服务端。React Server Components、Vue 的服务端能力、Qwik 的 Resumability，都是这条线。

给程序员的一句话建议

不要背框架 API，要理解它的「响应式模型」。
当你真正搞懂了「它是组件级还是节点级、是 Pull 还是 Push、是编译时还是运行时」，你在任何框架里都能预判性能、定位 bug、做对选型。框架会过时，模型不会。

2026 年没有「最好的框架」，只有「最合适你当下业务的框架」。但如果你问我长期主义该往哪投资——请把时间花在 Signals 和编译时思维上，因为它们是这一代框架共同的未来。

深扒依赖追踪：30 行手写一个 mini Signal，看清 Push 模型本质

光看框架行为不够过瘾。我们花 30 行代码手写一个最迷你的 Signal，把「细粒度响应式」的引擎拆给你看。理解了它，你就理解了 Solid 和 Vue 的心脏。

// 极简 Signal：演示 Push（主动推送）模型的依赖收集
let currentEffect = null;

function createSignal(value) {
  const subscribers = new Set();
  return [
    // getter：在「响应式上下文」中被读取时，把当前 effect 注册为依赖
    () => {
      if (currentEffect) subscribers.add(currentEffect);
      return value;
    },
    // setter：更新值，并「推送」给所有订阅者（无需重新扫描谁依赖了它）
    (next) => {
      value = typeof next === 'function' ? next(value) : next;
      subscribers.forEach(fn => fn());
    },
  ];
}

function createEffect(fn) {
  const effect = () => { currentEffect = effect; fn(); currentEffect = null; };
  effect(); // 立即执行一次，执行期间读 getter 即完成依赖收集
}

// 演示
const [count, setCount] = createSignal(0);
createEffect(() => console.log('count =', count())); // 收集依赖，打印 count = 0

console.log('--- 触发更新 ---');
setCount(5); // 推送：自动打印 count = 5
setCount(c => c + 1); // 推送：自动打印 count = 6

这段代码揭示了一切：

• getter 不是普通取值，而是「登记」：谁在读我，谁就是我的订阅者。
• setter 不是普通赋值，而是「广播」：我变了，立刻通知所有订阅者重跑。
• 没有虚拟树，没有 Diff，没有「重新执行组件去发现依赖」。依赖关系在 createEffect 第一次运行时就被钉死，之后全是 O(订阅者数量) 的精准推送。

对照来看，React 是 Pull（惰性拉取）模型：它不预先建订阅图，而是每次 setState 后重新执行组件函数，重新读 state，才「重新发现」谁用到了新值——这就是为什么 React 的更新粒度天然是组件级，因为它重跑的单位就是「组件函数」本身。

Solid 的 createSignal / createMemo / createEffect 就是上面这个 mini 版本的工业级实现，只不过它把「订阅者」精确绑定到了具体的 DOM 节点或具体的 memo 节点，而不是整个 effect 函数，从而做到节点级更新。Vue 的 ref/reactive 基于 Proxy 做依赖收集，原理同源，差异只在「依赖边界是组件」还是「节点」以及「编译期插桩多少」。

Solid 迁移实战：「组件只跑一次」埋下的三个经典坑

如果你是从 React 转 Solid，最反直觉的一点就是：组件函数体只执行一次。这带来三个高频踩坑点，提前知道能省你三天调试。

坑一：顶层的一次性逻辑不会随更新重跑。

// ❌ React 习惯：把「每次渲染都要变」的东西放在顶层
function Bad() {
  const id = Math.random();        // Solid 里永远固定，因为函数体只跑一次
  const now = new Date().toISOString(); // 也是固定值
  return <span>{id} {now}</span>;
}

// ✅ Solid：需要随状态变化的，放进 signal / 或放进派生
function Good() {
  const [id, setId] = createSignal(Math.random());
  const [now, setNow] = createSignal(new Date().toISOString());
  return <span>{id()} {now()}</span>;
}

坑二：条件分支要用响应式原语，不能裸 if return。

// ❌ 裸 if：Solid 里组件只跑一次，loading 变化不会切回主视图
function Bad({ loading }) {
  if (loading()) return <Spinner />;
  return <Main />;
}

// ✅ 用 <Show>：分支本身是响应式的，loading 变化自动切换
function Good() {
  return <Show when={!loading()} fallback={<Spinner />}><Main /></Show>;
}

坑三：列表默认用 <For> 而非数组 map。 React 的 array.map 每次重渲染都重新生成元素再 Diff；Solid 的 <For> 做细粒度 keyed 复用，增删一项只动那一项，不重渲染整个列表。

一句话总结迁移心法：在 Solid 里，「渲染」这个概念被拆成了「初始化（跑一次）」和「更新（按 signal 精准触发）」。把 React 的「每次渲染」思维翻译成 Solid 的「初始化 + 响应式绑定」，就通了。

RSC、SSR、Resumability：三条「减少客户端重渲染」的路线

细粒度框架解决的是「重渲染发生了，怎么让它更便宜」。另一派思路更直接：让重渲染根本不发生，或者不在客户端发生。三条代表性路线：

1. SSR（服务端渲染）
服务端把组件渲染成 HTML 字符串发给浏览器，客户端再 hydrate（注水）——也就是在浏览器里重跑一遍组件、重建响应式系统，把事件和处理函数「接」到已经存在的 DOM 上。问题是：hydration 成本高，而且客户端照样要加载整套框架 runtime 和响应式系统。重渲染的负担只是被「延后」了，没有消失。

2. RSC（React Server Components）
React 19 把组件分成「服务端组件」和「客户端组件」。服务端组件在服务器渲染、直接序列化成 RSC 负载，不进入客户端 bundle，也不参与客户端重渲染。适合「数据近、交互少」的区块（比如文章正文、商品详情）。它从架构上把一部分 UI 踢出了客户端响应式系统，从而减少了需要重渲染的总量。

// 服务端组件：不带 'use client'，运行在服务器，永不客户端重渲染
async function ProductDetail({ id }) {
  const product = await db.products.find(id); // 直接读数据库，零网络往返
  return <article><h1>{product.title}</h1><p>{product.desc}</p></article>;
}

3. Resumability（Qwik 的可恢复式）
Qwik 走了最极端的路：它不在客户端做 hydration，而是把应用状态和事件处理器序列化进 HTML，浏览器按需「恢复（resume）」某个交互，而不是「重新执行（re-hydrate）」整个应用。从根上消灭了「加载即重渲染」的开销。代价是序列化的元数据和「懒恢复」带来的首次交互延迟需要精细调优。

三者的共同点：都在试图回答同一个问题——「能不能别让客户端承担那么多响应式负担？」它们和细粒度框架并不冲突，反而可以叠加：用 RSC 把静态部分搬到服务端，用 Solid/Svelte 把留下的动态部分做得飞快。

总结展望：2026 年到底该选谁

把前面的分析收敛成一张选型决策表：

三个 2026 年的确定趋势

1. Signals 成为通用词汇。 不管你用不用 Solid，理解「Signal / 细粒度订阅图」都会成为前端基本功。它正在从「Solid 的专利」变成「全行业的底层语言」。

2. 编译时压倒运行时。 Svelte 证明了编译时响应式的可行性，Vue Vapor、React Compiler 都在向「把工作从浏览器搬到构建期」靠拢。未来框架的竞争，越来越是编译器的竞争。

3. RSC / SSR / 流式渲染融合。 「客户端重渲染」的另一个解法是「别让它发生」——把不常变的部分放服务端。React Server Components、Vue 的服务端能力、Qwik 的 Resumability，都是这条线。

给程序员的一句话建议

不要背框架 API，要理解它的「响应式模型」。

当你真正搞懂了「它是组件级还是节点级、是 Pull 还是 Push、是编译时还是运行时」，你在任何框架里都能预判性能、定位 bug、做对选型。框架会过时，模型不会。

2026 年没有「最好的框架」，只有「最合适你当下业务的框架」。但如果你问我长期主义该往哪投资——请把时间花在 Signals 和编译时思维上，因为它们是这一代框架共同的未来。

延伸阅读建议：想动手对比，建议把本文四个版本的计数器单独跑一遍，在 DevTools Performance 面板录一次 +1，亲眼看看 React 的 reconcile 调用栈和 Solid 的「裸赋值」有多大差距。再试着跑一遍上面那个 30 行 mini Signal，改改 getter/setter，体会 Push 模型「依赖即注册、变化即广播」的清爽。眼见为实。