7.2 核心库与插件：生态对照矩阵

7.2 核心库与插件：生态对照矩阵

本节摘要：React 生态的宽度是选型者的安全感来源，迁移的最大心理障碍也在这里。本节按赛道给出对照矩阵：路由、状态、请求、表单、无头组件五条核心赛道 Solid 都有官方或社区默认答案；图表、编辑器、后台模板等长尾赛道存在缺口，应对策略是"优先复用框架无关的底层库"。读完你能量化一个项目的生态迁移成本。

「生态位」这个词在框架比较里常被滥用，本节给它一个可操作的口径：一个库的生态位等于它解决的问题加上它与框架渲染模型的耦合深度。耦合浅的（工具函数、算法库、样式方案）跨框架通用；耦合深的（依赖重渲染模型或 Hooks 约定）必须换。矩阵的每一行都按这个口径标注耦合深度，迁移成本立刻可见。

核心赛道矩阵

表里有个规律值得指出来：必换的格子集中在"深度耦合渲染模型"的赛道，而它们的 Solid 侧答案 API 形状大多有意识地向 React 侧靠拢——这是生态后发者的生存策略，学习成本被刻意压低了。真正要花时间的不是学新 API，是重做选型决策。

图：生态对照矩阵——按耦合深度排布的迁移盘面

长尾赛道的应对策略

图表库、富文本编辑器、重型表格这类长尾，Solid 生态的成熟度确实不及 React。应对策略按优先级排：优先找框架无关的底层（图表用底层数据驱动渲染的方案，编辑器用无头内核），自己包一层薄绑定——在信号模型下这层封装往往只有几十行；次选社区已有的绑定包；都没有时，评估该功能是否值得隔离成一个微前端或 iframe 岛。经验上，管理后台的中后台组件密度高，是长尾缺口痛感最重的场景；内容型应用反而几乎感知不到。

另一个常被忽略的选项：把 React 组件通过双框架桥接嵌入 Solid（社区有运行时共存方案）。技术上可行，包体积与两套渲染模型并存的复杂度是实价，只建议作为"过渡期缓冲"，不是长期架构。

💡 评估生态成本的速算法：数一数项目的 package 依赖里有多少个"名字里带 react"的包，再按矩阵把每个归进三色区。多数中型应用的结果是绿五黄二红一——工期按红色那一格估，而不是按总数估。

四条赛道的选型短评

矩阵给了坐标，短评给理由。无头组件赛道：Solid 侧的 Kobalte 一脉提供"行为无头、样式全权"的组件内核，可访问性与键盘交互内建，与 Tailwind 组合是当前社区默认搭配；从 Radix 迁来的团队 API 体感相近，主要工作是逐组件核对待遇差异。表单赛道：轻表单直接信号直绑（5.3 的受控模式），重表单选社区的 schema 驱动方案，选型时重点验证三件事——嵌套字段、数组字段、异步校验，这三点覆盖了复杂表单八成的坑。

请求赛道：TanStack Query 官方提供 Solid 适配，缓存与失效策略原样保留，useQuery 换成信号化的读取，与 createResource 的分工是"重缓存策略用它、轻量声明用内置"——两者不冲突，按页面权重分配。元信息赛道：官方 meta 库管标题、描述、社交卡片，API 十行内学会，从 react-helmet 迁来基本是删代码。

问题：能不能继续用 Ant Design 或 MUI？

不能直接用，也不建议桥接长期用。组件库是渲染模型耦合最深的品类：受控逻辑、合成事件、context 消费全部长在 React 运行时上。短期桥接（社区的双框架运行时共存方案）适合迁移过渡期撑住个别重型组件，长期答案要么换 Solid 侧组件方案（Kobalte 系加自建主题，工作量可控；社区也有仿 Ant 风格的组件集），要么承认这个项目此刻不适合离开 React。诚实地把这条写进选型文档，比迁到一半才发现要自建组件库要体面得多。

本节要点回顾

• 生态位看耦合深度：与渲染模型耦合浅的库跨框架通用，焦虑常被高估。
• 核心赛道有默认答案：路由、状态、请求、无头组件、元信息，官方或社区一梯队齐备。
• 长尾策略是自封装：框架无关底层加薄绑定，信号模型让封装层很薄。
• 工期按红区估：组件库与复杂表单的重选型是迁移成本的主要来源。

工具集与垂直件的补充

矩阵之外还有两类常被问起的依赖。工具函数层：React 生态的 hooks 集合类库（防抖节流、事件监听、媒体查询一批）在 Solid 侧由社区原语集合对位提供，这些能力多数本就该自建——响应式原语让"自己写一个 useDebounce"的成本降到十行以内，依赖该省就省。垂直件层：二维码、剪贴板、文件预览这类小功能件，优先找框架无关的实现自己包壳；包壳成本在信号模型下普遍低于 React 版本，因为没有重渲染协调问题要处理。

图标与动效两件值得点名：图标库走"按需导入单文件组件"的路线两边一致；动效方面 Solid 有内建的指令式过渡方案（配合 CSS 过渡与生命周期钩子），复杂编排仍交给框架无关的动效引擎，边界清晰。

版本与维护的观察习惯

生态选型还有一门功课：判断一个 Solid 侧库值不值得进依赖清单。看四格信号。维护节奏：近半年的提交与发版记录，响应式框架的库随内核语义演进，长期停更的库风险高于 React 世界同位。语义版本：破坏性变更有没有走版本号纪律，变更记录是否说人话。类型质量：TypeScript 类型是手写的还是生成的，props 的类型约束能不能在编辑器里给你正确提示。测试与示例：有没有可运行的最小示例，示例跑不跑得通。四格信号过一遍仍合格的库，进清单；有一格含糊的，优先找替代或自建——Solid 的自建成本曲线比 React 侧更平，这一判断经常成立。

下一节回答"人怎么办"——给 React 开发者排一条最短学习路径。