页面切过去要转两三秒，来回点几下直接卡死。这种体验问题在 Next.js 项目里太常见了，尤其是升级到 App Router 之后。
最近我一直在做一个迁移项目，页面数量不算多，功能也不复杂，但用户反馈切换路由时体感极差，最严重的时候甚至要刷新页面才能恢复。一开始我以为是部署环境网络差，或者服务器性能不行，查了一圈才发现，问题全在自己的代码组织方式和 App Router 的渲染机制上。这个过程走完，我把 App Router 路由卡顿的排查思路、高发根因、以及真正能落地的修复方案理成了这篇文章，希望能帮正在被路由卡顿折磨的人少走几个弯路。
这篇文章适合三类人：一是刚接触 App Router 就被页面切换延迟困扰的开发者；二是接手了一个体感卡顿项目、正愁不知道从哪查起的人；三是想提前把性能优化做进项目规范、避免将来踩坑的团队技术负责人。下面我会把排查链路、工具用法和修复代码尽量拆细，争取让不同基础的读者都能照着上手。
1. 先定量，再定性：你的页面到底属于哪种"卡"？
卡顿这个词太笼统了。很多朋友一反馈"页面很卡"，实际上表达的是完全不同的三件事。不先分清楚这三件事，后面所有排查都可能跑偏。
第一类是延迟：点下链接之后画面迟迟切不过去，等待时间肉眼可见地长，但一旦新页面出来，滚动、点击都正常。这类问题典型表现是白屏时间过长，或者 loading 页面停留过久。它在浏览器里表现为网络请求慢、服务端响应慢，或者前端在等一个迟迟不返回的数据。
第二类是卡顿：页面切换成功后，新页面的内容虽然出来了，但滚动不跟手，点击按钮要等半拍才有反馈，输入框打字都掉字。这是交互层问题，通常是 JavaScript 在主线程上执行太久，阻塞了渲染和事件响应。
第三类是假死：路由切到一半彻底没反应，页面像被冻住了，过好几秒才恢复，甚至必须刷新才能救回来。这种情况多半是某个异常引发同步死循环、无限重渲染，或者某个资源加载彻底把主线程堵死。
这三类症状表面相近，但底层机理完全不同，修复手段也几乎不重叠。如果一开始不分清类别，很容易对着错误的方向调半天，越调越乱。
那怎么定量区分？我建议建立一套简单的体感基线，不要凭感觉说"卡"，而是把数字记下来：
- 切页延迟：在点击入口与下一页主要内容渲染之间记录时间差。一般来讲路由切换从点击到新页面可交互，超过 500ms 用户会明显觉得慢，超过 1s 基本就是"卡"了。
- 长任务：浏览器主线程上超过 50ms 的连续任务就是 Long Task。录制一次切换过程，把最长的长任务时长记下来。
- 新页面 FCP：新页面首次绘制有效内容的时间。这个值能帮你区分"数据慢"和"渲染慢"。
- INP：衡量整体交互延迟的指标，新建页面后点击按钮如果响应超过 200ms，已经需要警惕。
我习惯在项目里留一个不提交生产的调试开关，把关键时间点输出到控制台：
// app/debug/timing.ts // 仅供本地排查使用，不要带到生产环境 export function logNavigationTiming(tag: string) { if (process.env.NODE_ENV !== "development") return; const t = performance.now(); // 在页面组件的 useEffect 里调用，记录新页面挂载时间 console.log(`[nav] ${tag} mounted at ${t.toFixed(2)}ms`); }1.1 一个快速判断切页类型的实验
排查前，我通常会先做一个最朴素的实验：把某个复杂页面临时换成只包含一个标题的空白页，从上一个路由切过来，看还卡不卡。
如果换成空白页之后延迟明显下降，说明问题集中在目标页面的数据加载、组件渲染或包体积上；如果换成空白页之后依然卡顿，那问题多半出在路由机制层面，比如全局 Provider、布局组件、中间件或 prefetch 策略。
这个实验只花五分钟，但能把排查范围直接缩小一半，后面很多工作都不用白做。
1.2 量化数据出来后，下一步该往哪个方向看
拿到上面几组数字之后，方向基本就清晰了：
- 网络请求慢，总延迟高，但主线程没有长任务：优先查服务端数据、请求瀑布、缓存策略，走的是 Network 排查和请求并行化、缓存配置的路线。
- 主线程长任务突出，FCP 不慢但点击响应差：优先查客户端组件范围、水合开销、大列表渲染、Provider 重渲染。
- 包体积异常，每个路由的 First Load JS 都很大：优先查动态导入、静态 import 大库、bundle 拆分。
- 切页后才开始加载大量资源，Network 瀑布在导航后密集发出：优先查 prefetch 与缓存、路由级预取策略。
这套对应关系不是绝对真理，但大多数项目都适用。拿着数据往下推，比在项目里四处乱翻高效得多。
2. 追根溯源：App Router 路由卡顿的六类高发根因
搞清楚"卡"的类型后，接下来要弄明白 App Router 里到底哪些机制会直接导致切换变慢。相比旧版 Pages Router，App Router 的切换流程发生了根本变化：客户端拿到的不再是一整份完整 HTML，而是 RSC payload 和序列化后的组件树描述，客户端需要根据这份描述重新协调渲染。这个机制带来了细粒度缓存和按需加载的好处，但也让性能问题的藏身之处变得更多。
以下六类是我在实际项目里碰到过、也在讨论里反复看到的高发原因，几乎覆盖了绝大多数"App Router 很卡"的案例。
2.1 服务端请求瀑布：串行 fetch 让总耗时线性叠加
App Router 鼓励组件自包含地请求数据：每个服务端组件都可以直接 await fetch。这个特性用起来很爽，但天然有个陷阱——如果父组件先 await 了一个请求，等数据回来后渲染子组件，子组件又 await 自己的请求，那么整个页面加载时间就是所有请求耗时的累加。
举例，一个页面有用户信息、订单列表、推荐商品三个区域，接口响应分别是 300ms、400ms、500ms，如果三个组件嵌套且各自独立发请求：
- 串行模式总耗时：300 + 400 + 500 = 1200ms
- 并行模式总耗时：Math.max(300, 400, 500) = 500ms
这就是请求瀑布。它不会让页面"卡死"，但会让路由切换后的等待时间变得非常漫长，尤其在后端接口本身慢的时候，体感极其糟糕。
这个根因在 DevTools 里很好辨认：切换到新页面后，看 Network 面板里的请求瀑布图。如果请求是一个接一个地发出，条状图呈现斜线排列，而不是在同一个时间段内并排存在，基本就是它了。
2.2 客户端组件边界过大：水合负担把主线程拖垮
App Router 里服务端组件不会把执行代码发给客户端，只有标了"use client"的组件及其依赖才会打进客户端 bundle。很多项目为了图省事，在布局组件、页面容器上随手加"use client"，或者因为一个小 onClick 就把整棵子树变成客户端组件。这样一来，被拖进客户端 bundle 的代码量会滚雪球式增长。
更关键的是，每次路由切换的"水合"开销也会跟着膨胀。所谓水合，是 React 在服务端渲染出的 HTML 之上，重新绑定事件、恢复状态的过程。水合需要执行大量 JavaScript，主线程一旦被长时间占用，用户在新页面上的每一次点击都会被阻塞。表现就是：新页面内容秒出，但点哪里都像隔着一层棉花。
2.3 动态导入时机不当：该拆的没拆，该等的又等了
Next.js 本身会按路由做代码分割，这是 App Router 默认行为。但问题往往出在路由内部：一个客户端页面里塞了图表库、编辑器这类体积巨大的库，并且在组件顶层用静态 import 引入。这样一来，虽然路由级别被拆开了，但进入这个页面的那一刻，所有大库都要一次性下载并解析。
另一种常见错误是动态导入用错了时机。比如在组件渲染过程中调用动态 import，而不是在事件处理里调用，导致首屏加载被一个异步分包卡住。动态导入本身没问题，但"在哪个时机导入"决定了它是优化还是新的瓶颈。
2.4 缓存策略缺失：每个切换都在重复往返服务器
路由切换后是不是每次都重新请求服务端，很大程度上取决于缓存策略。App Router 里 fetch 的默认缓存行为在不同版本之间并不完全一致，所以尽量不要依赖"默认会缓存"这种假设，而是要主动声明。比较常见的坑有：
- 在 fetch 请求上写死
cache: "no-store"，导致每次进入页面都重新请求接口。 - 页面内部使用了
headers()、cookies()这类动态 API，导致整个路由无法被静态化或增量缓存，每次切换都走完整的数据请求流程。 - 明明是可以预渲染的内容，却没有用
generateStaticParams去生成静态页，导致每次导航都触发服务端执行。
这些情况在 Network 面板上的表现是一样的：每次切换路由，都会看到一串真实的网络请求。正常有缓存策略时，很多请求应该直接复用，而不是每一下都完整走一遍网络。
2.5 客户端大列表与重计算：主线程被同步任务塞满
很多"切换后卡死"的案例，最后都定位在客户端组件里渲染大列表或执行重计算。路由切换时 React 需要协调新页面组件树，如果里面有成千上万个 DOM 节点要生成，或者有大量数据在客户端做过滤、排序、格式化，主线程就会被长时间占住，浏览器顾不上绘制，表现就是"卡死"。
这类问题有时甚至和网络无关：哪怕所有数据都在本地，渲染本身也会阻塞。我也见过把日期格式化、正则替换这类操作直接写在渲染函数里的，数据量一上来，渲染一次要几百毫秒，整个页面连滚动都掉帧。
2.6 全局状态与 Provider 滥用：状态更新引发整树重渲染
App Router 项目里常见的组合是：在根布局挂上全局的 SessionProvider、ThemeProvider、CartProvider，然后把大量组件塞进 Provider 的消费范围内。问题在于，一旦某个 Provider 的 value 变了，所有消费了它上下文的组件都要重新渲染。
如果这个 Provider 恰好放在布局层，而它的 value 在整个页面切换过程里频繁变化，那么每次路由切换都可能引发大范围客户端重建。这不是路由变慢，而是全局状态把路由渲染拖慢了。尤其坑的是，很多 Provider 的 value 是一个每次渲染都生成新引用的对象字面量，连锁触发所有订阅组件重渲染。
3. 逐层揪出元凶：一套可以直接照做的定位流程
很多朋友拿到这类问题，习惯一上来就改代码：看到卡就加缓存，看到慢就加动态导入。这种盲猜优化运气成分太大，而且优化完了也很难说清是哪个改动真正起了作用。我的做法是执行一套自上而下的排查流程，每层都有明确判定标准，找到哪层异常，再去那层深挖。
3.1 第一步：Network 面板看请求链
在 DevTools 的 Network 面板里，先勾选 "Disable cache" 关掉浏览器缓存，再手动触发一次路由切换。这一步只看两件事：请求的并行度和总耗时。
切页时如果发现请求一个接一个地发出（瀑布图右侧条状是斜排而不是并排），而且总耗时接近各请求耗时的累加，基本可以锁死请求瀑布。如果总耗时主要来自某一个服务端页面数据请求，思路就转向服务端数据获取那一层，而不是在客户端反复折腾。
3.2 第二步：Performance 面板看主线程
Network 面板里看不出"卡"，只能看出"慢"。要确认主线程是否被阻塞，用 Performance 面板录制一次完整的点击到渲染过程。录制结束后重点看两处：
- 火焰图中是否存在连续的长任务，单次超过 50ms 的任务会被标红。记下最长的那个任务以及对应的函数名。
- 点击事件之后到绘制之间，有没有大段密集的 JavaScript 执行区域。
如果点击事件一发生，主线程上立刻弹出一个 500ms 的大函数，就别折腾网络了，去 React 层找这个函数是哪来的。
3.3 第三步：React DevTools Profiler 找渲染热点
Network 和主线程分析不出来时，进入 React 层。用 React DevTools 的 Profiler 录制切页过程，看组件树里哪些组件 render 时间最长、哪些组件在导航后发生了无意义重渲染。
这里有个判断技巧：如果一个组件的 props 没有变化、依赖数据也没有变化，但它仍然高频重渲染，而且 render 时间特别长，那十有八九是上下文或父组件状态泄漏。点击该组件，查看 Profiler 里"这次更新是谁触发的"信息，通常能直接指出是父组件渲染、context 变化还是 props 变化造成的。如果是父组件渲染导致，就顺着父组件的触发原因继续往上追。
3.4 第四步：bundle 体积分析查包问题
next build的输出会给每个路由列出体积预估。如果某个路由标红的体积特别大，或者在 First Load JS 一栏的数字明显偏离基线，说明这个路由被打进了不该进来的代码。
要更细地看，可以临时接一个 bundle 体积分析工具，构建完能看到每个 chunk 由哪些模块组成。看到诸如"同一个图表库被打进了所有页面"或"动态导入变成了静态依赖"这类情况，根因基本就清楚了。
3.5 第五步：最小复现，隔离变量
如果上面四步做完还没有锁死，就做最小复现项目。新建一个只包含两个路由的 demo，把怀疑的配置、Provider、请求钩子逐项搬进去，每搬一项就测一次切页耗时。
这个方法很笨，但极其有效。App Router 的性能问题往往由多个因素叠加产生，最小复现能帮你把变量一个一个隔离出来，而不是在庞大的项目里做无谓猜测。
4. 针对六类根因的落地方案：修到点子上才会有效
定位完成后，剩下就是修复。下面按根因给方案，每个方案都给出可以直接用的代码或配置写法。这里多提醒一句：不要试图一次把所有问题都改完。很多复杂项目会同时存在两三类问题，一次改动过多反而无法确定每个改动的实际效果。我习惯按"对体感影响最大"的项从高到低排优先级，改一项、测一项、确认一项，再动下一项。
4.1 打破请求瀑布：并行化与 Suspense 边界
请求瀑布的修复思路有两个方向：一是让请求并行，二是利用 Suspense 边界让部分请求不阻塞整棵组件树的渲染，先到先渲染。两条可以配合使用，根据页面结构决定优先级。
先说并行。如果是同一个组件内的多个请求，把多个 await 改成 Promise.all 即可。这是最直接也最不容易出错的改动，适合几个请求互相独立、没有数据依赖的场景：
// 修复前：串行请求 const user = await fetchUser(userId); const orders = await fetchOrders(userId); const ads = await fetchAds(userId); // 修复后：并行请求 const [user, orders, ads] = await Promise.all([ fetchUser(userId), fetchOrders(userId), fetchAds(userId), ]);如果是不同组件层级的请求，可以引入 Suspense 边界，让每个区域独立加载：
// app/dashboard/page.tsx import { Suspense } from "react"; export default function DashboardPage() { return ( <main> <Suspense fallback={<UserSkeleton />}> <UserSection /> </Suspense> <Suspense fallback={<OrdersSkeleton />}> <OrdersSection /> </Suspense> </main> ); }这样即使订单接口很慢，用户信息区域也能先显示。每个 Suspense 的 fallback 只占一小块，比整页一起转圈体感好得多。
注意：Promise.all 不是万能的。如果接口之间有依赖关系（比如必须拿到用户 ID 才能查订单列表），就不能简单并行，需要改用"先加载用户信息、再加载订单"的分步 Suspense 方案。
4.2 收缩客户端边界：把大部分代码留在服务端
"服务端优先"是 App Router 的性能准则。操作手法很简单：
- 凡是纯展示、纯数据取数的组件，一律不加
"use client"，保持服务端组件身份。 - 只有真正需要交互事件、使用 useState、useEffect、useContext 等客户端 hook 的组件才加
"use client"。 - 更进一步的思路是把客户端组件下沉到叶子节点。比如一个卡片组件需要点击事件，不要给整个卡片加
"use client"，而是把需要交互的那个按钮单独拆成一个客户端子组件，卡片整体仍然保持服务端组件。
// Server Component，不标记 "use client" import { LikeButton } from "./LikeButton"; export function ArticleCard({ article }) { return ( <div className="card"> <h2>{article.title}</h2> <p>{article.excerpt}</p> {/* 只有这个按钮是客户端组件 */} <LikeButton articleId={article.id} /> </div> ); }这种改造表面上看动静不大，效果却非常明显。客户端 bundle 体积会往下降，水合需要执行的 JS 也少很多，切换后的首屏交互响应会有质的提升。
4.3 动态导入的正确姿势：拆包粒度与导入时机
对体积大、且不一定要在首屏加载的库，用动态导入把它拆出去：
"use client"; import dynamic from "next/dynamic"; const Chart = dynamic(() => import("./PriceChart"), { loading: () => <ChartSkeleton />, ssr: false, // 纯客户端渲染的图表组件不需要服务端渲染 });动态导入的关键点有三个：
- 粒度：按模块拆，而不是把整个页面文件一起动态化。拆到"一个库一个组件"级别，效果最明显。
- 时机：在组件顶层调用
dynamic()，不要在渲染循环或编译阶段动态导入业务库。真正需要在事件发生时加载的，是那种低频操作（比如点击后才展开的编辑器、弹窗里的导入向导），这种场景才把动态导入放在事件回调里await import()。 ssr: false：对于依赖 window 或 document 的纯客户端库必须设置，否则服务端渲染阶段会报错或拖慢速度。
另外，next/dynamic在服务端组件里使用要特别注意。如果在服务端组件里用dynamic()导入组件，导入的是服务端组件区块，不会减小客户端体积。绝大多数情况下，只有"use client"组件里用next/dynamic才真正起到给客户端减负的作用。
4.4 配置级缓存与预渲染：让高频页面不再重复计算
针对"每次切换都重复请求"的根因，可以从三个层面配置缓存。
第一层：静态化。能用generateStaticParams就绝不手写动态请求。比如以 slug 为参数的新闻页面：
// app/news/[slug]/page.tsx export async function generateStaticParams() { const posts = await fetchAllPostSlugs(); return posts.map((post) => ({ slug: post.slug })); }配合默认的静态渲染行为，这个页面在构建时会预渲染成静态页面，运行时切换路由根本不需要重新请求服务端。
第二层：增量缓存。数据是动态的、但更新不频繁的，用 revalidate 做时间窗口缓存：
export default async function Page() { const data = await fetch("https://api.example.com/data", { next: { revalidate: 300 }, // 5 分钟内复用缓存 }).then((res) => res.json()); return <Main content={data} />; }或者用export const revalidate = 300设置路由级别的重新验证周期。
第三层：客户端缓存。频繁切换且数据几乎不变的路由，可以依赖 Next.js 的客户端路由缓存。要注意不要为了图省事在页面上到处写cache: "no-store"，这等于放弃全部缓存优化。只在确实需要实时数据的地方才使用 no-store。
4.5 长任务拆解：列表虚拟化与低优先级更新
客户端列表渲染阻塞主线程，最直接的解法是虚拟化。只渲染可视区域内的节点，比如 10000 条数据降到几十条，主线程占用会瞬间回归正常。常用的虚拟化方案包括 react-window、@tanstack/react-virtual 等，接入成本不高，收益却很划算，值得优先做。
除了列表本身，数据转换类任务不要放在渲染函数里：
// 错误示范：每次 render 都重新格式化 const items = rawData.map((item) => new Intl.DateTimeFormat("zh-CN").format(item.date) ); // 正确思路：在数据源头格式化，或在 useMemo 里缓存 const items = useMemo( () => rawData.map((item) => new Intl.DateTimeFormat("zh-CN").format(item.date) ), [rawData] );如果转换任务特别重，比如要处理几十万条记录，可以考虑分片执行，或者干脆把逻辑挪到服务端组件、Server Action 里。App Router 提供了这些能力，就不要再让客户端硬扛。
4.6 Provider 拆分与上下文隔离：防止一棵树全量重建
全局状态这一类问题的修复可以从两点入手。
第一，把 Provider 往下移到真正需要它的子树根节点。如果只有购物车页面用 CartProvider，就别挂到根布局。这样其他路由切换时根本不会触发它的重渲染。
第二，对必须挂到布局层的 Provider，对 value 做记忆化处理。比如用 Zustand 这类支持 selector 的状态库，让组件只订阅自己关心的片段：
const items = useCartStore((state) => state.items); const addItem = useCartStore((state) => state.addItem);如果必须用 Context，可以把 Provider 的 value 包进useMemo，避免父组件每次渲染都生成新引用。Context 的坑在于 value 引用不稳定时，所有使用该 context 的组件都会被拖下水，最常见的触发点就是父组件里写了 setState，但没有同步保证 value 引用稳定：
const value = useMemo(() => ({ items, addItem }), [items, addItem]);这一小步能消除一大批无意义重渲染，尤其是布局层这种高频渲染位置的 Provider。
5. 用数据守住成果，让性能问题不再回头
修完之后不是结束，而是开始。路由性能问题有个特点：它很容易在后续迭代里悄悄复发，而且通常不是同一个位置以同样的方式复发，而是新代码以新的形式逐渐拖慢旧的成果。你不建立护栏，性能就会在一次一次功能迭代中被不知不觉蚕食掉。
5.1 建立上线前的基准指标
优化前测出的基线值和目标值，一定要写进文档，而不是只记在脑子里。我一般会定义几条：
- 目标路由的"点击到可交互"时限：小于 500ms。
- 目标路由的 First Load JS 体积：小于某个设定阈值，阈值按项目复杂度定，不能一刀切。
- 每次构建后检查
next build输出的各路由体积，超过阈值就警告。
这些数值不一定适合所有项目，但"有明确基线"这件事比基线定多少更重要。后续迭代里只要数据开始反弹，就能第一时间发现，而不是等到用户抱怨了才回头找。
5.2 用 CI 或预提交检查堵住回归
可以在 CI 脚本里增加一个体积检查，解析next build的构建输出，也可以用社区的性能审计工具在每次 PR 时跑一遍核心指标，超阈值直接阻断合并。做法不复杂，但能真正把性能优化固化进协作流程。
一个简单思路是：把本次next build的输出缓存一份，下次构建后解析出每个路由的 JS 体积，与上次对比。如果某个路由增长超过一定比例且超过预设绝对值，就输出警告甚至让流水线失败。
5.3 团队约定：把性能规范写进评审清单
技术守护只能挡一半，另一半要靠代码评审和团队文化。我建议在代码评审清单里加几条硬性约束：
- 新组件默认不加
"use client"，确实需要再加，加的时候说明理由。 - 引入新依赖时检查它被打进哪个路由，体积多大，能不能用动态导入。
- 修改布局或新增 Provider 时评估影响范围，禁止为了省事把 Provider 直接放根布局。
- 涉及数据请求的改动，先确认会不会新增串行瀑布。
这几条看着简单，但执行起来能挡住大多数回潮问题。实际经验是：App Router 项目的性能问题，绝大部分不是框架 bug，而是代码组织方式在慢慢劣化。团队只要坚持"服务端优先、客户端做减法、Provider 不下沉"这三个原则，路由性能就不会轻易退步。先修架构，再谈优化，这句话在 Next.js 世界里尤其适用。
最后再分享一点个人操作习惯：每次做性能优化，我都会顺手把排查过程里发现的关键路径整理成简短文档，贴在项目的 README 或内部 Wiki。等下次又有人反馈"页面很卡"，照着这份地图走一遍，几分钟就能定位问题发生在哪个环节，而不是把整个项目重新翻一遍。这种"留一手"的做法，往往比优化本身更能帮你省时间。
