刘文柱

# next架构总览与核心设计

# next 到底在解决什么系统性问题

很多人把 Next 理解成“React + SSR”，这会低估它的价值。
从架构角度看，Next 在做的是把前端工程里最难统一的 5 件事收敛成一个模型：

  • 路由（URL -> 页面/布局）
  • 渲染（SSR/SSG/ISR/Streaming）
  • 数据（获取、缓存、失效）
  • 服务端能力（BFF、鉴权、写操作）
  • 构建部署（本地、CI、生产运行时一致）

核心收益不是“语法更少”，而是认知负担和协作成本降低。

# 从 Pages Router 到 App Router：设计范式变化

# Pages Router 的优势与边界

Pages Router 的模型简单清晰，但在中大型应用有几个痛点：

  • 页面级数据获取导致复用成本高
  • 布局复用需要手工方案（getLayout 等）
  • SSR + CSR 混合策略不够细粒度

# App Router 的关键升级

App Router 把路由和布局都提升为 segment（目录层级）概念，让“页面结构”与“渲染边界”天然对齐：

  • layout.tsx：稳定外壳
  • page.tsx：叶子内容
  • loading.tsx：异步占位边界
  • error.tsx：错误边界
  • template.tsx：需要重新挂载时的边界

这意味着 Next 不再是页面级渲染工具，而是分段可恢复渲染系统。

# 运行时分层：Server Components 与 Client Components

# Server Components（默认）

特点：

  • 在服务端执行，可直接访问数据库/服务端 SDK
  • 不进入浏览器 bundle（减少客户端 JS）
  • 更适合内容渲染、数据拼装、权限预处理

# Client Components（"use client"）

特点：

  • 在浏览器执行，支持事件与 hooks
  • 会进入客户端 bundle
  • 适合交互控件、表单、本地状态管理

# 实战分工建议

  • 列表页外壳、SEO 文本、基础数据读取：放 Server Components
  • 筛选面板、弹窗、拖拽、富交互区：放 Client Components

一句话：把“能在服务端算完”的都尽量留在服务端。

# 请求到首屏的完整链路（高层时序）

  1. 请求进入 Next runtime（Node 或 Edge）
  2. 路由匹配到 segment 树
  3. 执行服务端组件，触发数据读取
  4. React 生成 HTML 与 Flight（RSC payload）
  5. 按 Suspense 边界流式输出
  6. 客户端接收并 hydration，交互区接管

关键理解：

  • HTML 负责“先展示”
  • Flight 负责“恢复组件语义”

所以 Next 输出的不是单一静态字符串，而是可恢复的分层渲染数据流。

# 为什么说 next 是“前端主导的全栈”

它并不是让前端去写传统后端，而是把 BFF 能力内聚到同一工程模型：

  • route.ts：接口层（鉴权、聚合、透传）
  • Server Actions：写操作与表单动作
  • next/cache：缓存和失效策略

对团队的直接价值：

  • 前端可以在同一仓库闭环完成“页面 + 数据编排”
  • 后端接口形态更稳定（由 BFF 做协议适配）
  • 发布链路更短

# 源码理解地图（先职责再文件）

阅读 Next 源码不要先“找文件名”，先建立职责地图：

  • 路由解析层：URL 如何映射 segment
  • 渲染调度层：何时开始 render，如何处理 streaming
  • Flight 编码层：Server Components 结果如何序列化
  • 响应输出层：HTML 与 payload 如何拼接输出
  • 客户端恢复层：如何基于 Flight 做 hydration

当你按职责追踪，源码会从“碎片”变成“可推演系统”。

# 生产案例：电商商品详情页架构拆分

场景目标：

  • SEO 强（商品标题、描述、结构化数据）
  • 交互重（SKU 选择、库存、加入购物车）
  • 数据更新频繁（价格、促销）

推荐拆分：

  • Server Components：商品基础信息、SEO、相关推荐（可缓存）
  • Client Components：SKU 面板、购买按钮、即时状态
  • Route Handler：价格聚合与促销策略（BFF 层）
  • 缓存：详情 revalidate + 标签失效（活动变更后定向刷新）

收益：

  • 首屏快且可索引
  • 客户端包体下降
  • 活动变更可精准失效，不需要全站重建

# 团队级落地规范（强烈建议）

# 目录分层

  • app/(site)：用户站点
  • app/(admin)：后台
  • app/api：Route Handlers
  • lib/server：服务端数据访问
  • components/client：交互组件
  • components/server：展示组件

# 代码治理

  • 禁止在 Client Components 里直接访问服务端密钥
  • 统一封装数据访问层，避免页面直连多后端
  • 缓存策略必须和业务 SLA 对齐（新鲜度 vs 成本）

# 常见误区

  • 误区 1：把所有组件都加 "use client"，结果失去 App Router 价值
  • 误区 2：只看 SSR 不看缓存，导致服务端成本失控
  • 误区 3：把 Next 当纯前端工具，不做接口边界治理

# 小结

Next 的本质是一个“渲染-数据-服务端能力”统一框架。
真正的架构收益来自这条主线：
分层运行时（Server/Client） + 分段渲染（segment/Suspense） + 可控缓存失效（revalidate/tag）。

← next渲染策略与缓存机制 →