从纯前端视角理解渲染

Part A：心智模型重建

A. 你过去的纯前端世界

在纯前端里世界比较简单、干净：

浏览器加载一个几乎为空的 index.html
+ 下载一整包 JS
→ React 在浏览器里"画"出页面
→ 页面要数据？useEffect 里 fetch
→ 拿到数据 → setState → 页面局部重渲染

主要心智模型只有三句话：

• 页面 = 浏览器里用 JS 画出来的，服务器不碰页面长什么样。
• 数据 = 永远靠前端主动调后端接口拿。
• 更新 = 我手动 setState 或重新 fetch一切由我控制。怎么说呢，

痛点：SEO 差、首屏慢、每次交互都要等网络请求；还有代码中大量重复的 fetch‑setState 逻辑。

代码示例，纯前端拿列表数据：

// 纯前端——你熟悉的写法
function DocList {
const = useState;useEffect => {
fetch
.n => res.json)
.n => setDocs);},)，const createDoc = async => {
await fetch('/api/docs'。{
method的观点是，'POST',body: JSON.stringify,});// 写完后手动重新 fetch 一次刷新列表
const res = await fetch;const data = await res.json;setDocs，};return (

{docs.map => (

{doc.title}
))}
新建文档

);}

这套模型里服务器只提供"裸数据 API"，从不碰"页面长什么样"。

A. Next.js 的颠覆：服务器也会画页面

Next.js App Router 最大的不同是：React 既可以跑在浏览器，也可以跑在服务器。同一个组件，服务器上先跑一遍生成 HTML，再传到浏览器。

现在 "页面长什么样" 有两个生产者

1. 服务器: 首屏 HTML 是它生成的。React Server Components就在这层。
2. 浏览器: 后续交互、导航时React 在浏览器里继续画和更新。Client Components 在这层。

痛点：If you keep using old model you’ll miss out on automatic SEO,faster TTFB and less client‑side JavaScript.

Your new code looks like this :

// app/work/@directory/page.tsx
import { getDocList } from './action';export default async function Directory {
// No useEffect。no fetch,no useState
// list is fetched directly on server!怎么说呢，const list = await getDocList;return ;}

// app/work/@directory/action.ts
import { auth } from '@/auth';import { prisma } from '@/lib/prisma';export async function getDocList {
const session = await auth;// read cookie → know who you are
const docs = await prisma.doc.findMany({
至于where，{ userId: session!.user，.id }。orderBy: { updatedAt: 'desc' },});return docs，}

关键颠覆：Your component has no fetch。no useEffect,no setState;data is fetched while server is rendering component.

A. 渲染页面的三种基本方式

Avoid thinking in “static vs dynamic”. Instead ask “where does this code run and when?”.

方式 ：服务器在“建立时”画好

// . 列出所有已知的 slug
export function generateStaticParams {
return;}
// . fetch 加缓存
async function getPost {
'use cache';不过，cacheLife;return fetch.n);}
export default async function BlogPost {
const { slug } = await params;
const post = await getPost;// 用缓存版
return {post.content};}

• Pnpm build
• The stored HTML file is served directly – React never runs.
• Straight‑line performance。but content is frozen at build time.
• Seldom‑changing pages – docs,marketing pages,blog posts.

方式 ：服务器在“使用者每次请求时”画

// app/work/@directory/page.tsx
import { getDocList } from './action';按理说，export default async function Directory {
// auth reads cookies → forces dynamic rendering
const list = await getDocList;// every request hits DB
return ;}

• User request arrives – server runs your component.
• User‑specific or real‑time data。at cost of a DB round‑trip per request.
• User dashboards,aunticated content,frequently changing lists.

方式 ：浏览器里画

// app/work//content.tsx
'use client';import { useEditor,EditorContent } from '@tiptap/react';export default function EditorContent {
const editor = useEditor({
content: JSON.parse,onUpdate: => {
debouncedSave);},})，return ;}

• The initial HTML still comes from server for fast first paint and SEO – n hydration takes over.
• Lively UI parts that need browser APIs – editors,forms。animations.

三种方式对照表

A. 拿数据的两条方法

In a pure front‑end project you only have one path:

• Front‑end → fetch → setState
​ ​ ​ ​ ​ ​ ​ Now Next.js gives you two distinct roads:

路 A：服务器组件直接拿数据

// Server Component
// app/work/@directory/page.tsx
export default async function Directory {
const list = await getDocList;// runs on server!return 
}
再看完整链路。scss
使用者访问 /work/abc → Server receives request →
执行 Directory →
await getDocList
→ auth → read cookies → identify user
→ prisma.doc.findMany 查询数据库 →
返回文档列表 →
注入组件生成 HTML →
发送给浏览器
**路 A 的更新** 不再由前端管，而是由 **何时让服务器重新绘制** 决定。实现方式 👉 `revalidatePath`。

路 B：客户端组件里 fetch / 调用 API 
// Client Component ’use client’
function DocList {
const = useState;useEffect => {
fetch
.n => res.json)
.n;},)，const createDoc= async=>{ …}，}
**两条路关键区别对比**



 路 A （Server Component ) 
 路 B （Client Component ) 



代码在哪跑 
服务器 
浏览器 

如何获取数据 
await getDocList —直接查库 
fetch — 调接口 

如何更新 UI 
revalidatePath + Server Action 
setState + 手动 refetch 




**痛点**这方面，使用路 A 时新建文档后左侧列表不刷新——因为 **Router Cache** 持有旧渲染结果。解决办法是 `revalidatePath`。

A. 客户端 Router Cache：动态页面也会被记住 🚦️️️️️️️️️️️️️️️🧭🧭🧭🧭🧭🧭🧭🧭

这是最容易被误解、也最关键的机制。
两段式认知 :


负责算出完整 HTML。

负责软导航，并维护一个 **Router Cache** 来存放已经算好的 RSC payload。


比喻 :


政务大厅＝Server。

超级前台＝Browser Router Cache。

第一次查询后超级前台把复印件贴在墙上。

之后内部切换。不再去大厅查询，而是直接看墙上的复印件。





即使路由本身是 动态渲染只要 Router Cache 没被标脏使用者仍会看到旧内容。

A. 示例 —— Layout 中插槽被缓存 
// app/work/layout.tsx —— 静态 layout 持久化侧边栏
export default function WorkLayout {
return (

{
{/* 左侧 @directory 插槽——首次渲染后被 Router Cache 缓存 */}
``
{/*右侧内容随 navigation 改变*/}
`
{children}
`
}
`)
}
* 使用者打开 `/work/abc` → Server renders `@directory` 插槽 → Browser caches it.
* 使用者点击 “新增文档” → Server Action 写库成功，但 **左侧插槽仍然使用缓存**。| 操作 | 发⽣了什么 | 左侧列表是否更新 |
|------|------------|-------------------|
| F5 整页刷新 | 浏览器向 Server 发全新请求 → Server 重跑 `Directory` → 新数据返回 | ✅ |
| 应用内点击 “新增文档” + `revalidatePath` | Server Action 写库 ✅ + 标脏方法 → Browser 丢弃旧缓存并重新请求 | ✅ |
| 应用内点击 “新增文档” *仅*写库 | Server Action 写库 ✅。但没有标脏 | ❌ |

*Part B：revalidatePath 技术详解*

🛠️‍💡︎︎︎︎︎︎︎︎︎︎︎︎

`revalidatePath` 是 Next.js 提供的函数，用来 **标记指定方法缓存为陈旧**。
import { revalidatePath } from ‘next/cache’;

调用后该方法在 下一次访问时会重新渲染——重新执行服务组件、重新查询数据库、重新生成 HTML。

如果在 Server Action 中调用，它还能 立即刷新当前 UI。

三层缓存它会触及



层级 
位置 
作用范围 


Full Route Cache 
Server Disk/Memory 



 



Data Cache 

 <  td>/server 




The above may be messy due to formatting constraints—focus on final answer clarity.

Sorry for any confusion—here's a clean final version:

--- End of response ---