1. 嵌套布局与局部路由 (Nested Layouts)#

在早期的 Pages Router 中，页面切换往往意味着整个 React 树的重新挂载，或是需要通过自定义的高阶组件维持状态。App Router 通过文件系统路由实现了真正的嵌套布局。

通过在目录中定义 layout.tsx，Next.js 能够识别出哪些部分是持久化的，哪些部分是动态变化的。在路由跳转时，只有变化的 page.tsx 会被重新渲染，而上层的 layout.tsx 保持挂载状态。

1
// 这是一个 Server Component，仅在服务端获取侧边栏数据
2
import Sidebar from './Sidebar';
3

4
export default async function DashboardLayout({ children }: { children: React.ReactNode }) {
5
  const user = await fetchCurrentUser(); // 服务端直接获取数据，无需 API 中转
6

7
  return (
8
    <div className="flex h-screen">
9
      <Sidebar user={user} />
10
      <main className="flex-1 overflow-y-auto p-6">
11
        {children}
12
      </main>
13
    </div>
14
  );
15
}

这种架构带来了 Partial Rendering (局部渲染)：当用户在 /dashboard/settings 和 /dashboard/profile 之间切换时，DashboardLayout 及其内部的 Sidebar 状态（如滚动位置、输入框内容）将得以保留，仅有 children 部分被重新请求和渲染。

2. React Server Components (RSC) 的运行机制#

RSC 是 App Router 的灵魂。不同于传统的 SSR（服务端渲染后发送 HTML），RSC 允许组件在服务端执行并生成一种特殊的二进制格式（RSC Payload），随后在客户端进行流式解析。

sequenceDiagram
    participant Browser
    participant NextServer
    participant Database

    Browser->>NextServer: GET /dashboard
    NextServer->>Database: Fetch Data (Parallel)
    Database-->>NextServer: Result
    NextServer->>NextServer: Render RSC to Payload
    NextServer-->>Browser: Stream HTML (Initial) + RSC Payload
    Browser->>Browser: Hydrate Client Components

1
// ❌ 灾难写法
2
import ClientProfile from './ClientProfile';
3

4
export default async function ServerPage() {
5
  const user = await db.user.findUnique({ id: 1 });
6
  // user 如果是一个复杂的 Prisma 模型，它内部可能挂载了某些不可序列化的 getter
7
  // 这会导致整个页面渲染崩溃！
8
  return <ClientProfile user={user} />
9
}

1
import 'server-only'; // 如果有客户端组件试图 import 这个文件，构建时直接报错！
2

3
export async function getUserDTO(id) {
4
  const user = await db.user.findUnique({ id });
5
  // 剥离敏感信息和类方法，只返回纯数据
6
  return {
7
    id: user.id,
8
    name: user.name,
9
    createdAt: user.createdAt.toISOString() // Date 转字符串
10
  };
11
}
12

13
// app/page.tsx
14
import ClientProfile from './ClientProfile';
15
import { getUserDTO } from '@/lib/data';
16

17
export default async function ServerPage() {
18
  const safeUser = await getUserDTO(1);
19
  return <ClientProfile user={safeUser} /> // ✅ 安全穿越边界
20
}

3. Streaming 与 Suspense#

App Router 原生支持流式渲染。通过 React Suspense，我们可以将页面拆分为多个独立的区块，优先渲染静态部分，而将耗时的数据获取逻辑包裹在 Suspense 中。

1
import { Suspense } from 'react';
2
import { PostList, PostSkeleton } from './components';
3

4
export default function Page() {
5
  return (
6
    <section>
7
      <h1>Latest Posts</h1>
8
      <Suspense fallback={<PostSkeleton />}>
9
        <PostList /> {/* 内部进行异步数据获取 */}
10
      </Suspense>
11
    </section>
12
  );
13
}

Next.js 会立即发送页面的 HTML 骨架，并在服务端数据准备就绪后，通过同一个 HTTP 连接将剩余的 HTML 片段“推”给浏览器。这种方式显著提升了 TTFB (Time to First Byte) 和 FCP (First Contentful Paint)。

4. Server Actions：重塑数据突变#

传统的表单提交需要开发者编写 API 路由、处理请求验证、执行数据库操作，然后再通过前端 fetch 获取结果。Server Actions 将这一过程简化为函数调用。

Server Actions 本质上是基于 HTTP POST 的 RPC（远程过程调用）。当你在客户端调用一个声明了 'use server' 的函数时，Next.js 会自动发起一个请求，并处理参数序列化与结果返回。

1
'use server'
2

3
import { db } from '@/lib/db';
4
import { revalidatePath } from 'next/cache';
5

6
export async function createPost(formData: FormData) {
7
  const title = formData.get('title') as string;
8
  const content = formData.get('content') as string;
9

10
  // 1. 校验与持久化
11
  await db.post.create({ data: { title, content } });
12

13
  // 2. 触发服务端缓存失效
14
  // 这会通知 Next.js 重新生成 /posts 路径的 RSC Payload
15
  revalidatePath('/posts');
16
}

在客户端使用时，只需将其绑定到 form 的 action 属性：

1
import { createPost } from '../actions';
2

3
export default function PostForm() {
4
  return (
5
    <form action={createPost}>
6
      <input name="title" required />
7
      <textarea name="content" required />
8
      <button type="submit">发布文章</button>
9
    </form>
10
  );
11
}

这种模式不仅消除了 API 胶水代码，还支持 Progressive Enhancement (渐进式增强)：即使在浏览器禁用 JavaScript 的情况下，表单提交依然可以通过标准的 HTML Form 机制工作。

5. 业务踩坑：丧心病狂的四层缓存体系#

很多开发者从 Vite 或 CRA 转到 Next.js App Router 后，最大的疑惑就是：“我明明数据库里的数据已经改了，为什么页面刷新还是旧的？”

这是因为 Next.js 默认开启了极为激进的四层缓存体系。如果你不理解它们，你的应用将充满幽灵数据。

1. Request Memoization (请求记忆)： 在同一个 Server Component 渲染周期内，如果你 fetch 了同一个 URL 两次，Next.js 会拦截第二次请求，直接复用第一次的结果。这个缓存只在单次渲染期间存活。
2. Data Cache (数据缓存)： 这是跨越多次请求的持久化缓存。Next.js 拦截了原生的 fetch，默认把所有返回结果存到文件系统或 CDN。除非你配置 fetch(url, { cache: 'no-store' })，否则它永远不会向源站发新请求！
3. Full Route Cache (完整路由缓存)： 如果在构建阶段，页面没有使用任何动态函数（如 cookies(), headers()），Next.js 会把整个页面的 RSC Payload 和 HTML 静态化存起来（类似早期的 SSG）。
4. Router Cache (客户端路由缓存)： 这是浏览器内存里的缓存。当用户在客户端 <Link> 跳转时，被访问过的 RSC Payload 会被缓存在内存中（默认存活 30 秒 到 5 分钟），按浏览器的返回键瞬间秒开。

工业级解法：按需爆破缓存 (On-demand Revalidation)

在真实业务中，我们通常会在 Server Actions 里修改数据后，精准地炸掉特定的缓存：

1
'use server'
2
import { revalidateTag, revalidatePath } from 'next/cache';
3

4
export async function updateArticle(id, content) {
5
  await db.article.update(id, content);
6

7
  // 💣 爆破 Data Cache：重新拉取带有这个 tag 的所有 fetch 请求
8
  revalidateTag(`article-${id}`);
9

10
  // 💣 爆破 Full Route Cache 和 客户端 Router Cache
11
  // 让用户下次访问 /blog 列表页时看到最新数据
12
  revalidatePath('/blog');
13
}

熟练掌控这四层缓存，是精通 Next.js App Router 的终极分水岭。

6. 总结#

Next.js App Router 通过 RSC 实现了组件级的服务端渲染，通过嵌套布局优化了客户端导航体验，并通过 Server Actions 统一了前后端交互模型。虽然它引入了更高的架构复杂度（如理解 use client 边界），但其带来的性能上限和开发效率提升，标志着 React 开发进入了真正的全栈时代。