6.2 SolidStart框架：对照Next.js的全栈方案

6.2 SolidStart 框架：对照 Next.js 的全栈方案

本节摘要：SolidStart 之于 Solid，约等于 Next.js 之于 React：补齐路由约定、服务端渲染、数据预取与部署适配。本节给出它的架构图与项目形态，逐项对照 Next.js 的对应概念，讲清流式 SSR 在细粒度响应式模型下的特殊优势，并给出渲染策略的选择清单。

元框架存在的理由跨框架通用：单页应用解决不了的首次加载白屏、搜索引擎可见性、服务端密钥管理、边缘部署，需要在框架层给出统一答案。Next.js 对 React 做的事，SolidStart 对 Solid 再做一遍——但底座不同带来的行为差异，比路由器那一层大得多：服务端渲染的序列化与注水，恰恰是细粒度响应式最能发挥的地方。

项目形态与架构

用官方脚手架起项目：

npm create solid@latest
# 交互选择：Basic / With Auth / With Prisma 等模板
# 渲染模式：SSR / SSG / SPA（可后改）
npm run dev
​

生成的是 Vite 系工程：入口、路由目录、服务端代码同仓。架构上它是"编译器加适配器"的组合：编译期沿用第 3 章的模板克隆产物，服务端则由可插拔的部署适配层接管——同一份代码可以构建成 Node 服务、边缘函数或纯静态文件，部署目标在配置里切换，业务代码不变。

图：SolidStart 架构——一次流式请求的旅程

与 Next.js 的概念对位

表里最值得展开的是"组件同构"这一格。React 的服务端组件路线把组件分成服务端与客户端两类，序列化的是组件树的执行结果；Solid 没有走分类路线——所有组件两端共用，服务端把响应式图"跑一遍"产出 HTML 流，客户端注水重建同一张图。心智模型因此更统一：不存在"这个组件能不能放在服务端"的判断负担，只存在"这段代码读没读服务端资源"的判断。

渲染策略怎么选

三选一的判断清单。内容为主、更新频率低（文档站、营销页）：预渲染，构建期产出静态文件，CDN 直出，成本最低。数据个性化、实时性强（后台、工作台）：服务端渲染加流式，首屏与交互兼得。强客户端交互、几乎无 SEO 诉求（编辑器、游戏化工具）：纯客户端模式，部署退化成静态托管，运维面最小。三者可以在路由级别混用——营销页预渲染、工作台服务端渲染，同一个项目里共存。

⚠️ 服务端渲染下 Effect 不在服务端执行（没有浏览器可副作用），从 React 迁移的"数据获取放 useEffect"习惯在 SolidStart 里要换成路由级数据函数或资源预取，否则首屏 HTML 里没有数据，流式优势直接作废。这是全栈迁移里最大的一处习惯修正。

服务端函数实战：把密钥留在服务器

服务端函数是 SolidStart 里最贴近日常的设施，用支付回调外的常见场景演示——下单时服务端校验库存并落库，客户端只需调用：

import { action, useAction } from "@solidjs/router";

// 标记为服务端执行的函数：密钥与数据库连接只在服务端存在
const placeOrder = action(async (formData) => {
  "use server";
  const stock = await db.stock.find(formData.get("sku"));
  if (!stock || stock.count < 1) return new Error("库存不足");
  await db.orders.create({ sku: formData.get("sku"), userId: currentUser().id });
  return { ok: true };
});

// 组件里像调用本地异步函数
const submit = useAction(placeOrder);
<form action={placeOrder}>
  <input name="sku" />
  <button type="submit">提交订单</button>
</form>
​

对照 Next.js 的 Server Actions：意图一致——函数体在服务端执行，客户端拿到的是一个代理调用；差异在耦合面，SolidStart 的服务端函数与路由的动作语义（表单提交、重新验证）结合得更直接，表单无需额外事件代码即可触发服务端执行。从 React 迁移的团队最需要换的预期是："接口层"从独立的 API 目录收敛进了组件树附近，前后端的物理距离变短，安全边界则由执行标记显式划定。

渲染策略混用的一个真实布局

内容站加工作台的混合产品常这样落子：营销页与帮助文档走预渲染（构建期产出，CDN 直出，秒开且对抓取器友好）；登录后的工作台走流式服务端渲染（个性化数据、首屏快）；设置页里的重型编辑器走纯客户端（交互复杂、无 SEO 诉求）。三者在同一路由树里按路由粒度配置，部署层面由适配层把静态与动态产物分别投放到 CDN 与函数运行时。这比 Next.js 时代"整站一种策略再逐页覆盖"的习惯更外露——策略写在路由配置里，评审时一眼可见，也更容易在团队规范里制度化。

问题：已有 Next.js 项目，值不值得转？

先算三笔账。内容账：页面以内容为主、服务端组件用得浅，迁移收益小，别动。交互账：客户端状态复杂、重渲染热点多的页面占比高，迁移收益集中在这些页面，按 10.4 的渐进路径评估。工程账：团队同时维护两套元框架的心智成本，通常要求迁移在单个季度内完成一个闭环，拖长线是最大风险。三笔账里有两笔为正，才立项。

本节要点回顾

• 元框架补齐服务端：渲染策略、服务端函数、部署适配是三大件。
• 同构无分类：组件两端共用，服务端跑图产流，客户端注水重建。
• 流式与细粒度同源：按块就绪按块交互，是节点级更新心智在 SSR 的延伸。
• 策略按页面混选：预渲染、流式 SSR、纯客户端可以在同一路由树里共存。

下一章看生态全景——构建工具链、组件库与从 React 出发的学习资源。