SolidJS 核心指南

SolidJS 是一个声明式 UI 库，但它的工作方式和 React、Vue 都不完全一样。

最大的区别在于：Solid 不靠虚拟 DOM 做整树级别的重新计算，而是靠细粒度响应式，把变化直接送到真正受影响的 DOM 节点上。这件事会连带改变很多写代码时的直觉。

Solid 的核心心智

组件函数通常只跑一次

React 的组件会在状态变化后重新执行，Solid 通常不会。组件初始化后，真正继续变化的是内部的响应式订阅关系。

这会带来两个非常直接的感受：

• 不太需要反复思考“重新渲染后这个闭包还是不是最新的”
• 很多原本靠 memo、callback 之类优化的场景，在 Solid 里天生就轻一些

状态不是“触发整段 JSX 再跑一遍”

Solid 的状态变化，更像“哪个地方依赖了这个值，就只更新哪个地方”。

这种粒度很细，所以它的性能表现一直很强，也很适合高频交互、实时面板、复杂可视化这类更新密集的界面。

为什么大家会把 Solid 和 React 放在一起比较

因为两者都用 JSX，很多代码看起来也很像。

但真正写起来，很快就会发现区别：

• React 的主线是组件重跑 + Hook 组合
• Solid 的主线是信号驱动 + 订阅传播

表面相似，底层思路差不少。

Solid 最吸引人的地方

1. 性能非常稳

Solid 的性能优势不是靠“手动优化习惯”堆出来的，而是底层模型决定的。很多在 React 里需要额外斟酌的 rerender 成本，在 Solid 里天然就小很多。

2. 心智负担不重

它并不要求完全换一种模板语言，也不需要重新学习很多陌生语法。JSX 还在，组件结构也还熟悉，但状态流转方式更直接。

3. 和 DOM、第三方库相处自然

因为没有大规模 VDOM 协调过程，和图表库、动画库、DOM API 打交道时，往往比较顺。

什么时候适合考虑 Solid

• 界面更新很频繁
• 交互密集，对运行时效率比较敏感
• 喜欢 JSX，但不想背太多 rerender 优化心智
• 团队能接受相对小一些的生态

什么时候先别急着上

• 团队已经深度押在 React 生态
• 大量依赖成熟的 React 第三方库
• 项目更看重招聘面和生态标准化，而不是框架本身的运行时效率

现在看 Solid，不该只看库本体

Solid 近几年的主线已经不只是核心库，还包括：

• Solid Router
• SolidStart
• 数据获取和服务端渲染能力
• 流式输出、元信息、部署适配

如果只是把它当成“一个很快的 JSX 库”，会漏掉后面半套工程能力。