第 4 章：App Router：为 SAAS 性能而生

第 4 章：App Router：为 SAAS 性能而生

如果你在 1.4 节建立的算法思维是““计算原语””，那么 Next.js App Router 就是一个将这些原语““工程化””的集大成者。它是一个为解决 SAAS 应用（尤其是数据驱动和 I/O 密集型）性能瓶颈而设计的、高度优化的架构。

4.1. App Router：基于文件系统的路由

这部分是 App Router 的““数据结构””基础。

• 算法思维 (1.4)： 树 (Tree)

• 架构映射：

  你的 src/app/ 目录 就是 一个 路由树 (Routing Tree)。

  • src/app/ 是 根节点 (Root Node)。
  • src/app/dashboard/ 是一个 子节点。
  • src/app/dashboard/settings/page.tsx 是一个 叶子节点 (Leaf Node)，它定义了 /dashboard/settings 路径的内容。

这种““所见即所得””的树结构，让你对整个 SAAS 应用的结构一目了然。当你思考““这个页面在哪里？””时，你不再需要查找一个复杂的 Python urls.py 列表或 FastAPI @app.get(...) 装饰器；你只需要在文件树中 定位那个节点。

4.2. [Skill 实战]：深入 App Router 的文件约定 (page.tsx, layout.tsx)

这是对““路由树””进行 遍历 (Traversal) 的约定。

• 算法思维 (1.4)： 树的遍历 (Tree Traversal)

• 架构映射：

  当一个用户访问 /dashboard/settings 时，Next.js 并 不是 只渲染那个 page.tsx。它会执行一个 自底向上 的““布局收集””遍历，然后执行一个 自顶向下 的““渲染嵌套””：

  1. 收集 (自底向上)： 从 app/dashboard/settings/page.tsx 开始，Next.js 向上 遍历树，寻找 layout.tsx。

     • 找到 app/dashboard/layout.tsx (父布局)
     • 找到 app/(root)/layout.tsx (根布局)

  2. 渲染 (自顶向下)： React 开始渲染，就像一个递归的““洋葱””。JavaScript

     // 1. 渲染根布局
     <RootLayout>
       {/* 2. 渲染 Dashboard 布局 */}
       <DashboardLayout>
         {/* 3. 渲染叶子节点：Settings Page */}
         <SettingsPage />
       </DashboardLayout>
     </RootLayout>

  layout.tsx 文件定义了树上 非叶子节点 (Parent Nodes) 的 UI““骨架””。page.tsx 定义了 叶子节点 (Leaf Nodes) 的具体内容。这种嵌套布局是树形数据结构最经典的递归应用。

4.3. 核心革命：React Server Components (RSC)

这是 App Router 架构的““性能核心””。

• 算法思维 (1.4)： 哈希表 (Hash Table) / 缓存 (Caching) / 记忆化 (Memoization)

• 架构映射：

  RSC 默认在服务器上运行，它们可以 await 数据库查询。这为什么快？

  1. 消除 I/O 瀑布流： 它允许你在服务器上 await Promise.all()，并行获取数据，而不是像传统 React 那样在客户端““瀑布式””地 fetch 数据。

  2. 激进的自动缓存： 这是与““刷题””思维最接近的地方。

  在 Python 中，你可能用 @functools.lru_cache 来实现““记忆化””，其底层就是哈希表。Next.js 将这个概念提升到了 架构层面。

  Next.js 的 fetch 和 React 的 cache 就是一个内置的哈希表 (Memoization Cache)。 当你在一个 RSC 中 await fetch(url)，Next.js 会自动将结果存入一个 哈希表，键 (Key) 是 url，值 (Value) 是 Promise 或结果。 SAAS 实战场景：

// utils.ts
import { cache } from 'react'; // React 的““哈希表””
import { db } from '@/db';
// 用 'cache' 将数据库查询““记忆化””
export const getCachedUser = cache(async (userId: string) => {

return db.query.users.findFirst({ where: eq(users.id, userId) });

});
// layout.tsx
const user = await getCachedUser(id); // 第一次调用：O(n) 数据库查询
// page.tsx (在同一个渲染周期中)
const user = await getCachedUser(id); // 第二次调用：O(1) 哈希表查找

4.4. [Skill 实战]：RSC vs Client Component 的边界、职责和通信

• 算法思维 (1.4)： 图 (Graph) / 有向无环图 (DAG)

• 架构映射：

  如果说你的路由结构是一棵 树 (Tree)，那么你的 组件导入 (import) 结构 就是一个 图 (Graph)。

  • 节点 (Nodes)： 你的 .tsx 文件 (Button, UserAvatar, DashboardPage)。
  • 边 (Edges)： import 语句（例如 DashboardPage -> import UserAvatar）。

  这个图是 有向的 (Directed) (导入是单向的) 和 无环的 (Acyclic) (循环导入会被构建工具阻止，即 A -> B -> A 会报错)。

  "use client" 的真正含义：

  "use client" 指令不是一个简单的标签，它是这个 图遍历算法 的一个 规则。

  1. ““服务器””节点 (RSC)： 默认的节点类型。可以访问服务器资源（数据库、文件系统）。
  2. ““客户端””节点 (CC)： 用 "use client" 标记的节点。可以访问浏览器 API（useState, onClick, document）。

  核心架构规则（图遍历约束）：

  一个““客户端””节点 (CC) 绝对不能 import 一个““服务器””节点 (RSC)。

  为什么？

  • 算法视角： 这条规则确保了图的““安全””。““客户端””节点 (及其所有子图) 的代码最终会被下载到浏览器。如果它能 import 一个““服务器””节点，就等于试图在用户的浏览器里 import { db } from '@/db'。这是 绝对不可能 也是 极度不安全 的。

  • 架构通信 ( children 道具)：JavaScript

    那么，客户端组件 (如 src/components/ui/Dialog) 如何显示服务器内容 (如用户信息)？

    答案：控制反转 (Inversion of Control)，也就是 children 道具。

    // Page.tsx (RSC - "服务器"节点)
    import { Dialog } from '@/components/ui/dialog'; // "客户端"节点
    import { UserInfo } from '@/components/user-info'; // "服务器"节点
    
    const user = await db.query...
    
    return (
      <Dialog> {/* 渲染 "客户端" 节点 */}
        {/* "服务器"节点 UserInfo 在服务器上渲染为 HTML。
          然后，它作为 "道具" (prop) 被““注入””到 "客户端" 节点。
          Dialog 只是在图中为它留了一个““插槽””，它不““导入””它。
        */}
        <UserInfo data={user} />
      </Dialog>
    )

    这是比 import 更高级的图组合模式，也是 App Router 性能模型的基石。

4.5. [代码解析]：分析实战项目中的 src/app/[locale]/ 国际化路由结构

• 算法思维 (1.4)： 树 (Tree) / 动态参数 (Dynamic Parameters)

• 架构映射：TypeScript

  [locale] 是一个 动态路由段 (Dynamic Route Segment)。

  在我们的““路由树””中 (见 4.1)，[locale] 不是一个 静态节点 (如 dashboard)，它是一个 动态节点 或 ““通配符””节点。

  • src/app/
    • [locale]/ (动态节点)
      • dashboard/ (静态节点)
        • page.tsx
      • layout.tsx
      • page.tsx

  它是如何工作的？

  1. 路由匹配 (Tree Matching)： 当请求 GET /en/dashboard 进来时，Next.js 的路由器会 遍历 它的路由树。

     • en 不匹配任何静态节点 (如 about, pricing)。
     • en 匹配了 [locale] 这个 动态节点。
     • 路由器 捕获 (capture) 这个值：{ 'locale': 'en' }。
     • 路由器继续向下匹配 dashboard，成功。

  2. 参数传递 (Parameter Passing)：

     这个被捕获的 { 'locale': 'en' } 参数，会作为 props 自动传递给它下面的所有 layout.tsx 和 page.tsx。

  SAAS 实战 (src/app/[locale]/layout.tsx)：

  在这个布局文件中，我们将使用 next-intl (我们的国际化库) 来利用这个参数：

  import { notFound } from 'next/navigation';
  import { NextIntlClientProvider, useMessages } from 'next-intl';
  
  // 1. Next.js 自动将 "en" 作为 params.locale 传入
  export default function LocaleLayout({ children, params: { locale } }) {
    // 2. [算法]：哈希表查找
    // 我们从 `src/messages/en.json` (或 de.json) 加载消息。
    // 这通常在 middleware 中完成，或在这里 'await'。
    let messages;
    try {
      messages = (await import(`@/messages/${locale}.json`)).default;
    } catch (error) {
      notFound(); // 如果 'locale' 无效 (如 'xx')，跳转 404
    }
  
    // 3. 将消息传递给所有客户端组件
    return (
      <NextIntlClientProvider locale={locale} messages={messages}>
        <html lang={locale}>
          <body>{children}</body>
        </html>
      </NextIntlClientProvider>
    );
  }

  通过这种方式，[locale] 这个 动态树节点 成为我们整个 SAAS 模板国际化架构的 根。