在写过不少 React 业务项目之后我一度以为自己理解了“响应式”这三个字。直到我花了大半个周末把 Solid 跑通一个带表格、筛选、批量操作的中后台页面才猛然意识到我之前理解的响应式其实一直是“组件重新执行”的另一种说法。而 Solid 的细粒度响应式是完全不同的思路——它不重新执行组件不对比虚拟 DOM而是精确到把状态值和具体的 DOM 节点绑定起来变量变了对应的节点自己知道自己去更新。这种“通知到节点”的更新方式第一次跑起来会让人觉得有点不真实。如果你正准备学 Solid或者已经在用 Solid 但总觉得哪里没吃透这篇内容应该能帮你把底层逻辑梳理干净。我会结合自己的实践把细粒度响应式的工作原理、核心原语的用法、编译阶段做了什么、工程中的状态架构以及踩过的一些坑一次讲明白。1. 细粒度响应式它究竟解决的是哪一类难题先聊一个可能被忽略的问题我们平时写的 UI 框架到底把性能花在哪里在 React 的世界里状态一旦变化默认是“从根组件开始重新执行整棵组件树”然后通过虚拟 DOM diff 找出哪些 DOM 要变。React 有各种 memo 策略去拦截这个默认行为本质上是想方设法“减少重新执行的规模”。但细粒度响应式的思路不一样它假设“组件函数本身不需要因为数据变化而重新执行”。组件函数只是被调用一次用来创建 UI 结构和注册依赖关系。之后数据变化框架直接走到依赖这个数据的那个最小单元里更新。这个“最小单元”可能是某个 DOM 元素的文本节点、某个属性、某个列表项而不是整个组件。1.1 React 的虚拟 DOM 模型与 Solid 的更新模式对比为了把差异看清楚我用一个很简单的计数器来对比。React 版本的代码大概是这样的function Counter() { const [count, setCount] useState(0); return button onClick{() setCount(count 1)}{count}/button; }React 内部会维护一棵虚拟 DOM 树。每次 count 变化Counter 函数会重新执行生成新的 JSX 描述diff 之后再把文本更新进去。函数组件本身是个“每次渲染都要执行”的函数。Solid 版本长这样function Counter() { const [count, setCount] createSignal(0); return button onClick{() setCount(count() 1)}{count()}/button; }表面上 JSX 很像但差别非常大。Solid 的组件函数只在首次挂载时执行一次。之后点击按钮count 信号变了Solid 运行时会直接找到模板里读取 count() 的那个文本节点更新它的 textContent组件函数不会再跑一遍。你想想这种差异在大型页面里意味着什么。一个页面可能有几十个组件但一次点击只影响其中一个表格单元格里的数字。React 要处理的是“哪部分组件需要重新渲染以及虚拟 DOM 怎么 diff”Solid 直接跳过这些步骤把更新指令发到那一个文本节点上。1.2 为什么说“细粒度”是一种更贴近物理世界的更新方式“细粒度”这个词听起来很技术其实特别朴素。它就是在描述一个事实状态更新可以被切到尽可能小的粒度。打个比方你在一间办公室里需要每个人都了解最新通知。粗粒度的做法是每次通知更新召集全员开会从头到尾念一遍大家自己对照差异。细粒度的做法是提前告诉每个人“你只需要关注哪类通知”更新时只给相关的人发一条即时消息。明显后者更快、更省事也更难写错。Solid 等于把这条“即时消息”机制做到了框架层面。你用 createSignal 创建一个响应式值在模板里使用这个值编译器记录下了这个使用位置。值被重新赋值时运行时精确地通知这些位置。没有中间商赚差价没有协调过程。这是 Solid 在框架性能测试里经常排在前面的根本原因不是某个黑魔法而是它从架构上就避免了“大规模检查”的默认路径。2. 核心原语拆解Signal、Memo、Effect 的实际行为聊细粒度响应式绕不开 Solid 的三大原语createSignal、createMemo、createEffect。这三个东西共同组成了细粒度响应式的基础设施。很多人一开始会拿它们和 React 的 useState、useMemo、useEffect 做类比但这样想容易跑偏因为它们的执行模型完全不同。2.1 createSignal值不是重点订阅关系才是重点createSignal 返回一个数组第一个值是读取函数第二个是写入函数。这和 React 的“状态值 setter”一样吗表面像本质不同。React 里 state 和 setter 是配对出现的组件依赖它们产生可复用的渲染逻辑。Solid 里getter 是一个真正的函数它代表“对这个值的一次订阅”。const [count, setCount] createSignal(0); console.log(count()); // 0 setCount(5); console.log(count()); // 5count() 每次调用都读取当前值。如果这次读取发生在某个响应式上下文里比如模板、createMemo、createEffect 内部那么运行时会自动把“这次读取”注册成一个依赖后续 count 变化时这个上下文会收到通知。编译后的模板不会重新执行整个组件而是把每个读取信号的位置转换成独立的更新子块。所以你会发现return ( div h1{count()}/h1 p{user.name()}/p /div );当 count 改变时只有 h1 内部的文本节点被更新p 元素完全不受影响。这种级别的更新定位在 React 里基本做不到因为 React 的复用单位是组件。有一点需要格外注意信号的值可以是任意类型但在 JSX 里使用时一定得调用读取函数也就是写 count()而不是写 count。这是 Solid 新手最容易犯的错误。2.2 createMemo不只要缓存结果还要缓存依赖关系createMemo 和 React 的 useMemo 名称很像但含义不同。React 的 useMemo 是把计算结果缓存下来只有当依赖数组里的值改变时才重新计算节省的是同一轮渲染中的计算开销。Solid 的 createMemo 则是一个“订阅源”它既缓存计算结果也把内部读取的多个信号之间的关系固化下来。const [price, setPrice] createSignal(100); const [count, setCount] createSignal(2); const total createMemo(() price() * count());这段代码里total 是一个只读的计算得到信号。首次计算 total() 的时候运行时会自动记录到 price 和 count 的依赖列表中。后面 price 或者 count 任一变化total 会重新计算但如果两者都没变化多次读取 total() 直接返回缓存结果不会重复执行乘法逻辑。这里我强调一个使用心得涉及多个响应式值共同推导出的新值应该用 createMemo 包一层再交给模板。否则模板里如果直接写{price() * count()}这个乘法和读取操作会被编译到模板更新块里。结果虽然一样但在语义上它没有被缓存每一次依赖变化都会执行这个乘法虽然代价不大但如果后续在页面其他地方也需要这个总和你就得重复写或者被迫提升作用域。createMemo 更像是在数据流里修建一个中转站让后续的依赖全部指向它避免派生逻辑散落一地。还有一点createMemo 只会在依赖变化的时“惰性重算”但它也有一个“急切执行”版本叫 createComputed不过大多数场景用不到。我们做业务页面createMemo 的覆盖范围已经足够。2.3 createEffect副作用要放在该放的位置createEffect 是细粒度响应式体系里最接近“watch”的机制。它接收一个函数函数同步执行的过程中读取了哪些信号之后这些信号变化时函数会重新执行。const [user, setUser] createSignal(null); createEffect(() { const current user(); if (current) { document.title ${current.name} 的个人中心; } });这里 createEffect 自动追踪了 useruser 每次变化document.title 都会同步更新。它不用手动声明依赖数组这是很多写惯了 hooks 的人需要调整的地方在 Solid 里不需要列出依赖只需要在 effect 函数里“读取”依赖即可。不过这个自动追踪也是把双刃剑。如果在 effect 内部读取了多个信号或者读取信号的时机有分支依赖追踪会按实际执行过的代码来收集。如果你在 if 分支里只读了一个信号另一个信号在当前这一次没有读到那么后续它变化时就不会触发这个 effect。这要求你写 effect 时要尽量保证依赖读取是稳定、直接的不要过度依赖异步代码里的信号读取。createEffect 在底层其实依赖了“订阅-通知”机制。组件函数首次执行时内部所有信号读取都会建立依赖但 createEffect 和模板更新块的依赖是分开管理的它们都在同一个响应式系统里只是订阅方和触发方不同。3. 编译阶段做了哪些事为什么性能从源头被锁死Solid 最让我觉得有意思的部分不是运行时而是编译期。Solid 利用编译器把 JSX 模板编译成高性能的 DOM 更新指令因此运行时不需要保留组件树或者虚拟 DOM 来做差异对比。这一步直接把很多运行时的开销前置到了构建阶段。3.1 没有虚拟 DOM也没有组件树对比先看一个简单的组件输入和编译输出的思路。比如这段 JSXdiv span{name()}/span /divSolid 编译器的目标不是生成一个 describe 结构让运行时解释而是直接生成“创建元素”和“更新文本”的代码。大致逻辑是const el document.createElement(div); const span document.createElement(span); el.appendChild(span); // 建立更新逻辑 createRenderEffect(() { span.textContent name(); }); return el;当然真实编译输出比我这个示例复杂得多比如属性更新、列表更新、事件绑定都有专门的辅助函数。但核心思路就是这个模板里哪些部分依赖于信号编译时就把它拆成一个可以单独更新的“块”。运行时通过闭包把这些更新块和具体的 DOM 节点绑定起来。所以我常说Solid 的“无虚拟 DOM”不是一个宣传噱头而是架构上的必然。它不需要在更新后重新执行组件函数来生成新的“描述”自然就没有必要再对两棵描述树做 diff。该更新的位置在编译阶段就已经确定了。3.2 内置控制流组件是怎么配合编译的Solid 的 JSX 里不能用 Array.map 随意渲染列表更推荐使用For组件。为什么因为For参与了编译优化。它内部知道每一项对应哪个 DOM 节点当列表数据变化时它能够按 key 精确移动、插入、删除节点而不是重建整个列表。For each{items()} {(item) li{item.name}/li} /For这里的 items 信号如果从 3 项变成 4 项Solid 会只插入新项对应的 DOM已有的三项原样保留不会重复执行第一项的创建过程。如果用传统方式写items().map(...)编译器也能处理但不容易做到同样级别的节点复用因为函数式 map 本身的返回结果是一个新数组编译器对它做静态分析的余地小很多。这个差异在生产环境会影响什么假如你有一个 5000 行的表格用户只往末尾追加了一行。用For浏览器只需要创建一行节点并插入用 map 的方式可能会把整个列表的数据都重新读取一遍虽然没有重建所有 DOM但创建和更新绑定的成本明显更高。所以在实机构建中列表渲染永远优先选择For、Show这一类内置控制流组件它们不仅语义更清晰性能行为也更可控。3.3 编译器还做了哪些你不容易注意到的优化除了把模板拆成细粒度更新块Solid 编译器还会做属性静态化。比如一个div classbox的 class 不依赖任何信号就只创建一次。如果某个属性依赖信号比如class{active() ? active : }编译器会生成专门的属性更新函数在 active 变化时用 classList 操作来切换而不是用 setAttribute 整体重设。另外JSX 中事件绑定的处理也被编译成了 addEventListener 或原生事件赋值逻辑并且静态事件不会因为数据更新而重新绑定。这一点在 React 里反而需要你注意React 合成事件虽然有优化但在事件对象池、绑定时机等方面有自己的坑。Solid 这里更直接组件函数只执行一次事件绑定也只有一次。把性能“从源头锁死”这句话意思是你在写代码阶段就能根据数据流推断出更新路径而不是等运行时黑盒处理。4. 工程实战如何在真实项目里设计细粒度的状态流细粒度响应式给开发带来的一个直接感受是状态设计变得特别重要。因为组件不会整体重建数据在哪个层、信号放在哪直接决定了更新的精确程度和代码的可维护性。我做了几个项目之后总结了几个比较实用的模式。4.1 局部信号优先全局状态按需提升在 React 里受状态提升和 props 层层传递的影响我们经常会把数据放在很靠上的层再用 memo 去避免子组件无谓更新。Solid 没有这个问题反而是局部信号越精细更新越高效。比如一个筛选面板里面的关键字输入、下拉选择、日期范围我建议全部用组件内部信号管理不需要放在全局 store。只有真正需要跨组件共享的数据才提升出去。function FilterPanel() { const [keyword, setKeyword] createSignal(); const [status, setStatus] createSignal(all); return ( div input value{keyword()} onInput{(e) setKeyword(e.currentTarget.value)} / select value{status()} onChange{(e) setStatus(e.currentTarget.value)} option valueall全部/option option valueactive进行中/option /select /div ); }keyword 每次变化只会触发关联的输入框和后续依赖它的派生值更新。筛选结果如果被单独 memo 出来那么只有 keyword 或 status 变化才会重新计算列表其他部分完全不参与。4.2 跨组件状态靠 createContext 和信号组合跨组件共享状态时我比较习惯用 Solid 的 createContext 把信号封装成一个个小的 store。它不需要像 Redux 那样定义 action、reducer只需要把信号和操作函数一起传下去。const CartContext createContext(); function CartProvider(props) { const [items, setItems] createSignal([]); const addItem (item) setItems((prev) [...prev, item]); const removeItem (id) setItems((prev) prev.filter((item) item.id ! id)); const total createMemo(() items().reduce((sum, item) sum item.price, 0)); return ( CartContext.Provider value{{ items, addItem, removeItem, total }} {props.children} /CartContext.Provider ); }在子组件里通过 useContext(CartContext) 拿到的 items 是读取函数不是值本身。所以在 JSX 里要写items()在事件处理里可以写items().length。这个细节不纠正后面会出现一堆 undefined 报错。这种模式的好处是组件之间共享的是“响应式引用”拿到 items 的子组件订阅的是同一个信号。某个地方调用了 addItem所有依赖 items 的地方自然收到更新不需要手动通知。而且中间商就是 context 对象本身不能随便塞入普通函数比如把 items 值传进去再取那就断掉响应式了。4.3 异步加载、Suspense 与 ErrorBoundary 的配合Solid 的异步处理没有 React Suspense 那么复杂但也有一套自己的流程。lazy 加载组件可以用 lazy 函数配合 Suspense 显示 loading 状态。异步数据请求我也喜欢用 createResource它天然处理了 loading 状态和响应式重取。import { createResource, Suspense } from solid-js; async function fetchData(id) { const res await fetch(/api/items/${id}); return res.json(); } function ItemDetail({ id }) { const [data] createResource(id, fetchData); return ( Suspense fallback{div加载中.../div} div{data()?.name}/div /Suspense ); }这里 createResource 的第一个参数 id 可以是信号也可以是普通函数。当 id 改变时createResource 会自动重新执行 fetchData并且把新的数据发到 data 信号里。Suspense 和 createResource 是一对配合的机制资源第一次加载或重新加载时Suspense 会显示 fallback 的内容。我记得最初使用 createResource 时踩过一个坑如果资源在 createEffect 里被手动触发可能会导致依赖收集不完整。更稳的做法是让数据请求的触发条件绑定到响应式参数上让 createResource 自己管理加载状态而不是我们把 Promise 塞到一个普通信号里。5. 性能问题排查与常见的响应式陷阱细粒度响应式不是银弹。它把更新效率提得很高但如果代码里出现了隐式破坏依赖追踪的操作问题排查起来比 React 更隐蔽因为那种问题不会直接报错只会表现为“数据变了界面没更新”。5.1 解构 props 这个经典坑先说最经典的一个错误把 props 解构出来再使用。Solid 的 props 对象本身是响应式的你可以把它理解为一个包含了多个信号的快照容器。如果你这样写function Greeting(props) { const { name } props; return spanHello {name}/span; }name 是一个普通字符串读一次就失去了响应式。之后父组件传入的新 name 不会反映到子组件上。这是 Solid 社区最常见的“为什么页面不更新”的元凶。正确做法是保留 props 引用function Greeting(props) { return spanHello {props.name}/span; }或者想解构也有规范做法用 splitProps 明确分离静态和动态属性import { splitProps } from solid-js; function Greeting(props) { const [local, rest] splitProps(props, [name]); return span {...rest}Hello {local.name}/span; }splitProps 返回的 local 里面name 依然是响应式的因为它在内部保留了 getter 代理。这是我严重推荐的方式尤其在写通用组件时。5.2 在 createEffect 里异步读取信号的问题createEffect 的依赖追踪只发生在同步执行阶段。如果我在 effect 里先 setTodo然后 await再读取另一个信号那么 await 之后的读取不会自动建立依赖。这其实不算框架缺陷而是 JS 异步模型的固有特性。但工程里很多人没意识到。下面的代码就属于“看起来能工作但依赖不全”createEffect(async () { const list await fetchList(); const keyword keywordSignal(); // 这里 keyword 的变化不会重新运行整个 effect filterList(list, keyword); });要解决这个问题要么把需要监听的值提到 effect 头部读取要么用两个 effect 组合一个负责监控过滤条件一个负责执行异步请求。追根究底响应式是基于同步代码的订阅模型异步流程只是发出去的副作用不能指望框架自动回溯。5.3 内存泄漏与手动清理createEffect 和 createMemo 默认会在组件销毁时自动清理订阅关系但如果你手动创建了一些全局订阅比如 window 事件监听、resize 回调、定时器需要在 onCleanup 里手动清理。createEffect(() { const handler () console.log(window.innerWidth); window.addEventListener(resize, handler); onCleanup(() window.removeEventListener(resize, handler)); });Solid 的 onCleanup 很像 React 的 useEffect 返回值清理。但有个差别onCleanup 可以放在 createEffect 内部也可以放在组件顶层。放在组件顶层时它在组件销毁时执行这个机制很适合做第三方库的销毁逻辑。5.4 用 Solid Devtools 和手动日志定位更新位置排查性能问题时我先看页面实际卡顿发生在哪一段。切换到 performance 录制观察 Scripting 的时间如果耗时集中在一个文件的行号里基本能定位到是哪个更新块执行过重。也可以在 createMemo 里 console.log 统计计算次数确认是否有不必要的重复计算。Solid 官网有官方 Devtools 扩展安装后可以查看信号的依赖图。调试初期我推荐开着它直接在组件树里找到某个信号检查它有多少订阅者。如果订阅者数量远超预期就很可能是某个全局信号被太多组件读取需要考虑按模块拆分。6. React 开发者如何理解 Solid 的心智模型如果你是从 React 转过来的可能觉得 Solid 的语法有点别扭为什么组件里不能随便定义新的组件函数为什么 props 不能随便解构为什么依赖不能用数组声明这些问题背后其实是同一件事Solid 把组件的“渲染函数”当作一次性执行。它对代码的静态结构和执行时机有更高的要求但它换来了极其精确的更新。6.1 组件不是响应式的壳只是作用域在 React 里组件是天然的更新边界。父组件状态变了默认整棵子树都要重新渲染。在 Solid 里组件函数不会被重复调用组件这个大单位不是更新边界。真正的更新边界是模板里的每一个动态块。所以你在 Solid 里很少需要“避免某组件重新渲染”这种优化手段。代码组织更自由可以把局部状态放得很散不会担心子组件被牵连重跑。反而适合更细粒度地把相关逻辑放在同一个组件作用域内。6.2 依赖收集是自动的但你要理解何时收集、在哪里收集写 Solid 有一个潜规则信号读取必须在响应式上下文里发生才会建立依赖。模板、createMemo、createEffect 都是上下文。普通的事件处理器不是上下文你在 onClick 里读取信号不会导致任何依赖收集这是合理的因为事件处理器只执行一次它不需要跟随数据自动重跑。理解了这一点很多奇怪现象都能解释为什么在 context 里调用了 setSignal 但没看到组件更新因为 setSignal 只会通知依赖方如果你这次读取发生在一个普通函数里没有依赖方那就不会有任何反应。这恰恰是细粒度模型的严谨之处只通知真正订阅的节点。6.3 性能优化思路从“减少重渲染”变成“保持依赖图简洁”在 React 里性能优化的话题总离不开 memo、useCallback、useMemo 这些 API。在 Solid 里默认就不存在“组件重渲染”你根本不需要去利用 React.memo 做比较。你真正要做的是让每个信号只被该依赖它的地方读取不要用一个超大 store 塞满所有业务数据否则一个字段更新会触发所有读取了 store 里其他字段的地方重新计算。比如我一开始习惯把所有页面数据放到一个 context 里后来发现一个小输入框的 onChange 会导致整个 context 依赖方全部被通知。当然由于依赖是按字段粒度追踪的读取同名函数不一定每次都触发但如果你把整个 store 对象解构出来依赖范围就大了。所以项目里的倾向是小 store、多信号、按业务模块划分。这样每个状态变化的影响范围最小代码可读性也高。我个人建议把“依赖图”画出来谁读取了谁谁能修改谁。依赖图越简单排查问题越快。这份心智模型比任何 API 速查表都重要。7. 实际开发中我踩过的坑和最后的经验写到这里我把一些零散的实操体会整理出来。有些是在文档里能找到的有些是查 issue 和反复测试才确认的。这些经验不算宏大但能省下不少调试时间。第一个坑是关于数组操作的。Solid 的信号内部用的是引用比较如果你直接修改原数组并重新赋值比如setItems(items().push(newItem))这个写法是错误的因为 push 返回的是数组长度而不是新数组而且 setItems 收到的参数不是一个数组会直接导致模板读取报错。正确写法是返回新数组setItems([...items(), newItem])。第二个坑是Show与Switch的 fallback 问题。很多人觉得{condition() ? A / : B /}和Show when{condition()} fallback{B /}一样实际上在 Solid 里三元运算符在 JSX 中的处理不如Show那么细粒度。Show会保证只有分支切换时才创建或卸载组件而三元表达式在某些编译情况下可能不会做同样等级的优化。能写成Show的时候就别偷懒用三元。第三个坑是 CSS 类名的动态绑定。最初我从 React 过来习惯写className{active ? active : }。Solid 支持这个写法但如果类名变化很频繁我更建议用 class 指令class:active{active()}这种写法可以直接切换 class 而不用重建字符串语义上更清晰性能也更好。第四个坑是热更新时的状态丢失。Solid 的 HMR 做得不错但如果你把信号定义放在组件内部热更新会导致组件函数重新执行内部信号被重置这很符合直觉。但如果用模块顶层信号状态能跨 HMR 保留。所以对于需要长期保留的登录状态、配置信息我会优先放在模块顶层而不是组件内部。最后说一个让我下定决心把 Solid 用到生产项目里的真实体验。当时做一个报表页面表格里有两千多行每一行有多个状态字段用户通过搜索框实时过滤。用 React 写的时候整个页面的交互响应明显有卡顿每次输入触发整体重渲染即使加了 memo 也要处理大量 diff。迁移到 Solid 后搜索框输入只触发筛选项的变化表格的For按 key 精确重排行节点输入到显示结果的间隙几乎可以忽略。它不是靠某个微优化达成的而是整个更新模型从根上减少了工作量。所以如果你在纠结要不要尝试 Solid我的建议是找一个列表密集、状态量多的页面亲手从零实现一遍。只有真正写过一次这种细粒度的状态流你才会理解框架选择的取舍也才会在回到 React 项目时对性能优化有更本质的认识。框架都是工具但理解一种非主流的心智模型往往会让自己在主流生态里也变得更清醒。