1. Link 组件到底解决了什么问题

做 Next.js 开发的人，基本每天都在跟 Link 打交道，但说实话，很多人只是把它当成一个"长得像 a 标签"的东西在用。我见过不少项目，页面跳转全靠 Link 包一层，遇到动态路由、权限跳转、菜单高亮这些场景就开始踩坑。所以我想把这块一次性讲透，从原理到实践，把 Link 组件的全部关键点都掰开揉碎聊一遍。

先说清楚 Link 组件解决的核心问题：它是 Next.js 内置的客户端导航方案，负责在 App Router 和 Pages Router 架构下实现页面之间的无刷新跳转。这里有个容易被忽略的点，Link 组件不只是帮你渲染一个<a>标签，它背后还默认开启了一个叫 prefetch 的预取机制——用户鼠标悬停或页面空闲时会提前拉取目标页面的代码和数据，跳转的时候就感觉是秒开。这就是为什么很多从 React Router 转过来的朋友会觉得 Next.js 的页面切换特别顺滑。

这套方案适合谁参考？不管你是刚接触框架的新手，还是已经在项目里维护过几万行代码的中级前端，只要你想把导航的每一个细节都掌控住，这篇文章就值得往下看。我会把 Link 的属性、行为、边界情况、以及和useRouter、中间件的配合全部梳理一遍，还会附上大量我在真实项目里踩过的坑。

2. 先弄懂 Link 与原 生 a 标签的区别

2.1 这不只是"少个刷新页面"的区别

很多人以为 Next.js 的 Link 就是一个增强版 a 标签，核心卖点就是不发新请求、不刷新页面。其实这只是表面。我拆解一下底层差异：

使用原生<a href="/about">，点击后浏览器会向服务端发出完整请求，服务端返回整个 HTML，然后浏览器重新走一遍解析、构建、渲染流程，这中间白屏时间是实打实的。在 Next.js 里用<Link href="/about">，点击后框架拦截了跳转行为，通过 JavaScript 动态加载目标页面的数据，然后再用客户端渲染的方式把新的界面呈现出来。React 的 diff 机制让相同组件得到复用，避免了整套 UI 重绘。

这里有一个很多人不熟的细节：Link 组件在 App Router 下还承担了"路由缓存"管理。你把一个页面切走再切回来，如果目标路由已有缓存快照，Next.js 能直接复用，连重新请求数据都省了。这个机制在需要频繁往返的页面流里（比如列表页跳到详情页再返回）体感差异非常明显，旧数据瞬间呈现，页面状态几乎无缝衔接。

提示：如果你的页面需要严格的实时数据，这个缓存行为得额外处理，官方 API 里有router.refresh()这种补丁方案，但绝不要依赖"每次都重新请求"的假设。

2.2 同一个 href，但 Link 在背后做了三件事

当我解释 Link 比 a 标签多做了什么的时候，我通常会把它拆成三步：

第一步，事件拦截。Link 组件在所有浏览器事件里拦截点击操作，检查是否有 特殊键触发（比如按住 Cmd/Ctrl 新开标签页），如果有就放行浏览器默认行为；如果只是普通点击，就阻止默认跳转，改用客户端路由逻辑处理。

第二步，路由解析。框架会把 href 拆解成路由和查询参数，交给 Next.js 内部的导航处理器。这个处理器要检查目标路由是否存在、需要哪些数据请求、有没有前置拦截条件，然后才决定如何去"拼接"这个新页面。

第三步，资源准备。这一步对应的是 prefetch 预取——在空闲时间或者 hover 发生时，提前把目标路由对应的 JS Bundle 和必要数据拉下来。所以当你真的点下去的时候，代码已经在浏览器里等着了，只需要做组件渲染和数据合并，速度自然快。

这种设计思路其实是"工程优化换体验"的典型代表：通过预判用户意图，把将来要执行的的成本提前支付。你不需要理解 React 的底层层层 diff，只要明白一点：Link 不是壳子，而是一套有预取、有缓存、有路由解析机制的完整导航引擎。

3. 从基础到进阶：Link 组件的全部用法

3.1 最简单的的页面跳转写法

先看最基础的使用方式，在 App Router 结构下：

import Link from "next/link"; export default function HomePage() { return ( <nav> <Link href="/about">关于我们</Link> <Link href="/blog">博客列表</Link> </nav> ); }

href你可以直接传字符串，也可以传一个对象。字符串是最常见的做法，内部会被解析成完整的 URL 路径传给路由系统。

在 Pages Router 里，用法基本一致，只是 import 来源和项目结构略有差别：

// pages/index.tsx import Link from "next/link"; export default function HomePage() { return <Link href="/posts">文章列表</Link>; }

有几点细节值得注意：Link 的 子节点里必须可以渲染出<a>标签。也就是说你直接写<Link><div>xxx</div></Link>，虽然不报错，但它不会渲染出一个真正的链接元素，这对 SEO 和可访问性都不友好。早期版本里这是强制要求，现在框架宽松一些，但它内部的逻辑仍然依赖这个锚点元素来计算点击区域和触发行为。

3.2 动态路由的正确打开方式

项目中更多见的是动态路由场景，例如一篇博客文章地址是/blog/123，数字部分是动态的。动态路由的 href 写法有两种风格，我用一个实际案例演示：

// 方式一：模板字符串直接拼 <Link href={`/blog/${post.id}`}>阅读全文</Link> // 方式二：对象写法 <Link href={{ pathname: "/blog/[id]", query: { id: post.id }, }} > 阅读全文 </Link>

这两种写法在功能上等价，但适用场景不太一样。如果只是简单的拼接，模板字符串省事，一眼就能看出逻辑；如果动态参数非常多（比如筛选条件、分页参数、多个 ID 组合），对象写法可以把参数集中管理，代码看起来干净很多。还有一些项目会在 query 里携带来源追踪参数，比如utm_source、from=share这些，对象写法能避免一堆加号拼接。

我强调一个非常容易犯的错误：在 App Router 下，如果你用模板字符串拼接的是一个含有多级路径的动态地址，比如/blog/2024/10/hello-world，只要你的 pages（或 app）目录里的结构是/blog/[year]/[month]/[slug]，那模板字符串是完全没问题的。真正容易出问题的是在传入查询参数时忘了解码或者编码混乱，导致拼出来的 URL 里有特殊字符破坏了解析。这种情况建议用URLSearchParams或者对象写法，让框架去处理编码。

3.3 给 Link 传参数的两个进阶选择

除了 href，Link 还支持很多控制导航行为的属性。我看过无数项目只用到了className和href，非常可惜，因为最有价值的几个属性能帮你省不少事。

replace属性控制是否替换当前历史记录。默认情况下，用户从 A 页面跳到 B 页面，点浏览器返回是可以回到 A 的。但如果 A 页面是一个表单页，用户提交后跳到成功页，你再让用户从成功页返回 A 会很尴尬，可能会出现重复提交或者看到一个不该存在中间状态。这时候给 Link 加上replace，A 这条历史就会被成功页的记录替换掉，用户返回时直接跳过：

<Link href="/success" replace> 提交完成 </Link>

scroll属性控制跳转后是否滚到页面顶部。默认值为true，符合直觉，因为绝大多数页面切换我们希望从头开始看。但在某些场景下，你希望保持当前的滚动位置，比如在一个无限滚动的列表页里面，用户点击进入某条详情，返回时希望停留回原来的列表位置，而不是重新滚到顶部。做法：

<Link href={`/list/${id}`} scroll={false}> 查看详情 </Link>

还有一个容易被遗漏的属性legacyBehavior。这是在 App Router 和 Pages Router 并存期出现的兼容选项。老项目里经常有类似<Link href="/xxx"><a>文字</a></Link>的写法，新的框架会默认认为子元素必须是一个能渲染锚点的组件，但这个前提下你必须在子元素里显式写出<a>。如果你的项目是从早期版本升级上来的，建议直接在 Link 外层包一层 legacyBehavior，避免大规模改动：

<Link href="/about" legacyBehavior> <a>关于我们</a> </Link>

3.4 样式注入和动态 class

Link 本质上渲染出的还是<a>，所以你可以传className和style。这听起来平淡无奇，但在实际项目中，"当前导航页高亮"就是这个属性最常见的用途。做法是用usePathname获取当前路径，再跟目标路径比对：

"use client"; import Link from "next/link"; import { usePathname } from "next/navigation"; export default function Navbar() { const pathname = usePathname(); return ( <nav> <Link href="/" className={pathname === "/" ? "nav-link active" : "nav-link"} > 首页 </Link> <Link href="/blog" className={pathname.startsWith("/blog") ? "nav-link active" : "nav-link"} > 博客 </Link> </nav> ); }

这个场景里有几个边界值得注意。第一，usePathname需要在客户端组件里用，如果你的 Navbar 是服务端组件，需要拆一个子组件或者在组件顶部声明"use client"。第二，路径匹配时用startsWith要小心误伤——比如你的博客路由是/blog，后来又加了/blog-tips，那startsWith("/blog")会同时点亮两个菜单项。建议优先使用精确匹配，或者用一个工具函数做分段匹配。第三，Link 的样式继承问题：CSS 模块、Tailwind、styled-components 都能直接作用，但要注意全局样式里给a标签定义的伪类，比如a:hover颜色变化，可能会覆盖带className的样式，这种情况需要提升选择器优先级。

4. Link 的核心机制：prefetch 预取深入解析

4.1 预取是自动的，但不是无脑的

前面提到，Link 组件默认开启了预取。在 App Router 架构下，预取行为基于视口可见性：只要<Link>出现在用户视野范围，浏览器空闲时就会后台下载目标路由对应的组件代码和数据。如果页面很长，视口外的 Link 不会被预取，只有当用户滚动到那个区域，它才会被触发。

这个设计背后有一个很实在的出发点：带宽和加载成本的博弈。一次预取一个页面不算大，但如果页面里有一百个 Link，全量预取会让初始页面吃掉巨量网络资源，很可能让首屏速度不升反降。所以框架选择"按需预取"，把资源给最可能是用户目标的链接。

在 Pages Router 下，旧版本是 hover 时才开始预取，后来也加入了空闲加载机制。两个架构的预取策略不完全一致，如果你在做跨版本迁移，得清楚这一点，否则会看到截然不同的网络请求记录。

有个常见误解：预取是不是会把数据也拉下来？是的，App Router 下默认会连同服务端组件的 payload 一起拉取。所以如果你的某个页面有内部 API 调用，API 数据也会提前加载，前提是该页面没有标记为禁止预取。这就意味着，服务端组件的计算开销和数据库查询可能在一个用户还没点击的时候就发生了。对于消耗比较大的操作，下面要说的prefetch={false}就变得非常重要。

4.2 手动控制预取行为

你可以非常精细地控制预取：

// 禁止预取 <Link href="/stats" prefetch={false}> 查看统计报表 </Link> // 强制预取（即使不在视口内也预取） <Link href="/dashboard" prefetch> 控制台 </Link>

给prefetch显式赋值true会覆盖默认的视口可见性限制，立即请求目标页面的资源。这个属性我用的场景不多，如果页面确实关键，又等不起用户滚到那个位置才发现，才值得用。反过来，prefetch={false}则很常用，凡是目标页面有较重数据计算、需要身份认证判断的，都应该禁用预取，避免未登录用户触发一堆只有登录后才能访问的接口请求。

注意：实际观察中可以发现，即使设置了prefetch={false}，用户真正点击时还是会发起请求，只是没有预取这一步而已。所以它不会阻断正常导航，只是"提前量"没了。

4.3 预取对性能的双面影响

我在一个大型后台项目上做过一次实测。左边栏有 40 多个导航 Link，每个 Link 对应一个页面，平均每个页面的组件代码加数据大概 120KB。如果都开启预取，首屏加载后浏览器会自动拉取大量的 chunk 文件，虽然体感上导航变快了，但页面初始的网络吞吐量翻了好几倍，如果团队的网络环境一般，反而会出现卡顿。

最后我们的优化方案是：核心页面保留默认预取，低频页面一律加prefetch={false}，而常见的"下一步"操作路径（比如从列表到 create 页面）则显式加prefetch。这样既保证了主线路径的顺滑，又不会把资源浪费在用户大概率不会点的地方。

如果你还想深入这个层级，可以看一下浏览器的 Network 面板：当页面首次加载完成后，你会看到若干额外的.js请求正在悄悄发生，那些就是预取任务。逐步把不同 Link 的prefetch关掉再观察，你就能建立自己的资源调度直觉。

5. 动态路由和查询参数的深度处理

5.1 动态路径里的嵌套和可选参数

Next.js 路由系统里有一种目录结构叫 Catch-all 和 Optional Catch-all，例如/docs/[...slug]或/docs/[[...slug]]。用 Link 指向它们时，href 的写法和常规动态路由略不同：

<Link href="/docs/installation">安装指南</Link> <Link href="/docs/guides/getting-started">快速开始</Link>

[...slug]能匹配多级路径，[[...slug]]能匹配多级路径且支持缺省。对于前端来说，写 Link 时你不需要特别区分，只要 URL 路径自然写出来即可。但有一个细节：用对象写法时，query 的键名要和文件的动态段名称保持一致：

// 目标文件：app/docs/[...slug]/page.tsx // 期望路径：/docs/guide/start <Link href={{ pathname: "/docs/[...slug]", query: { slug: ["guide", "start"] }, }} > 文档 </Link>

注意这里slug传的是数组，因为[...slug]本身就会把多段路径解析为数组。如果只传一个字符串，部分版本会解析异常，导致路径丢失一段。这是我当年第一个踩上的坑，排查了将近半小时，最后发现 Network 面板里的跳转 URL 居然只有/docs。

5.2 查询参数的正确添加与更新

查询参数一般有两种添加方式：一是直接在 href 字符串里拼，二是用对象写法的query字段。我自己在维护筛选条件、分页器、分享链接时更倾向于对象写法，因为它让我能把"路由结构"和"附加数据"分离开。

// 拼字符串 <Link href={`/products?category=phone&page=2`}>下一页</Link> // 对象写法 <Link href={{ pathname: "/products", query: { category: "phone", page: 2 }, }} > 下一页 </Link>

这两种方式最终生成的 URL 一致，但对象写法有一个隐藏优势：天然帮你处理编码转义。如果你的参数值里包含特殊字符（中文、空格、&、=等），对象写法框架会安全编码，字符串拼接则必须你自己用encodeURIComponent处理，否则很容易产出畸形 URL。

我再提一个用户经常忽略的点：如果你需要保留当前所有 query 再追加一个参数，对象写法可以用扩展操作符快速实现：

const currentQuery = { ...searchParams, }; // 某些情况你还可以直接从 useRouter 拿 <Link href={{ pathname: pathname, query: { ...currentQuery, page: 2 }, }} > 下一页 </Link>

记住这个组合技巧，它在你做分页、多标签筛选、排序切换时能省下大量重复代码。

5.3 在服务端组件里用 Link 可以吗

App Router 默认推荐服务端组件，你可能在疑虑 Link 能不能直接在服务端组件里用。答案是可以，而且这是 Link 的一个独特优势。因为 Link 组件本身不需要交互状态，它在服务器上渲染出的是一个包含href的<a>标签；只有当浏览器加载这个 HTML 时，Next.js 才会在客户端对其做增强和预取的绑定。

所以你完全可以在一个 async 的服务端组件里循环输出多个 Link，不用添加额外的"use client"指令。例如从数据库取出文章列表后：

import Link from "next/link"; export default async function PostsList() { const posts = await fetchPosts(); return ( <ul> {posts.map((post) => ( <li key={post.id}> <Link href={`/blog/${post.slug}`}>{post.title}</Link> </li> ))} </ul> ); }

这个写法和服务端渲染结合得很好，页面初始 HTML 里直接包含真实完整的文章链接，对 SEO 非常友好。这是我很推荐的一种实践方式。

6. Link 与 useRouter：什么时候该用谁

6.1 用 Link 做声明式导航

在 React 生态里，我们经常讨论"声明式"和"命令式"两种编程方式。Link 是典型的声明式导航：你在 JSX 里描述"我要去哪里"，组件自己负责剩下的处理。绝大多数 UI 场景，比如菜单、按钮跳转、页脚链接、面包屑导航，都应该用 Link。因为它天然带有语义化和可访问性基础，还能获得框架的预取优化。

简单总结，适合用 Link 的常见场景：

• 导航菜单或侧边栏入口
• 内容列表中的"阅读全文"、"详情页"链接
• 页面中的 SEO 外链、友情链接
• 面包屑导航中每一层的入口
• 分页器

使用 Link 的时候，页面中只要出现指向某个路由的链接，搜索引擎和爬虫就能抓到链路关系。如果替换成按钮加事件跳转，爬虫会完全没有头绪，不利于索引收录。

6.2 必须用 useRouter 的场景

有些场景 Link 确实不好用，主要体现在"跳转时机或位置不是由静态 DOM 决定的"情况。比如：

1. 表单提交成功后跳转到成功页
2. 用户点击登录按钮，等接口验证通过后跳转 dashboard
3. 某些权限拦截逻辑判定后跳转 404 或 403
4. 倒计时结束自动跳转到另一个页面

这些情况下，使用useRouter()的push方法更顺手。这里有一个具体的示例：

"use client"; import { useRouter } from "next/navigation"; export default function LoginButton() { const router = useRouter(); async function handleLogin() { // 假设这里做了认证 await loginRequest(); router.push("/dashboard"); } return <button onClick={handleLogin}>登录</button>; }

注意这里用的是next/navigation里的useRouter，不是next/router。在 App Router 架构下，旧的next/router已不推荐使用，很多初学者还从旧文章里抄代码，导致运行时控制台报错。

useRouter还有几个实用方法：

• router.back()：返回上一历史记录
• router.forward()：前进到下一历史记录
• router.refresh()：刷新当前路由的数据，但不丢失客户端状态
• router.replace()：替换当前历史记录，等价于 Link 的replace属性

需要留意的是，refresh会重新请求服务端组件的数据，但不会重置客户端状态（比如 useState）。这在某些数据更新场景里有奇效——比如提交完表单后想更新列表但不想重置表单状态。

6.3 两者的混合使用策略

在实际项目中，我不会只选一种方式，而是有明确的边界。凡是可以被描述为"链接进入某页"的，用 Link；凡是依赖"某种条件成立后跳转"或"程序内部主动导航"的，用 useRouter。这个筛选逻辑能减少一半的导航 bug。

有一个常见的困惑：Link 能不能放进事件处理函数里动态生成？可以，但没必要。如果你在事件处理函数里已经有条件分支要判断，那么返回值会变得反直觉。不如直接在 onClick 里判断，再调用 router.push。

但我还是建议优先考虑在事件触发处渲染出一个动态 Link。例如在列表中判断某个对象的状态，如果是"已发布"，就渲染一个指向详情页的 Link；如果是"草稿"，渲染不可点击的按钮。这样用户不点击时也能从 UI 上判断这是一个可跳转的入口。

7. 大规模应用的导航架构实践

7.1 统一封装导航入口

很多项目一开始都是直接裸写 Link，散落在各个页面。等页面多了会出现各种不一致：有的用小写 href，有的用大写；有的带尾部斜杠，有的不带；有的已经废弃的页面还被 Link 指向，产生 404。后来我们开始做一个统一的导航组件库，集中管理常用路径常量。

我推荐的做法是：维护一个路由常量文件，避免手写分散的魔法字符串：

// lib/routes.ts export const ROUTES = { home: "/", about: "/about", blog: "/blog", blogDetail: (slug: string) => `/blog/${slug}`, userProfile: (id: string) => `/user/${id}`, admin: { dashboard: "/admin", settings: "/admin/settings", }, } as const;

然后用一个自己的AppLink组件去封装项目里需要的通用行为，比如自动添加统计参数、处理外部链接、统一 target 行为：

// components/AppLink.tsx import Link from "next/link"; import { ReactNode } from "react"; interface AppLinkProps { href: string; children: ReactNode; target?: string; onClick?: () => void; className?: string; } export default function AppLink({ href, children, target, onClick, className, }: AppLinkProps) { const isExternal = href.startsWith("http") || href.startsWith("//"); if (isExternal) { return ( <a href={href} target={target || "_blank"} rel="noopener noreferrer" className={className} onClick={onClick} > {children} </a> ); } return ( <Link href={href} className={className} onClick={onClick}> {children} </Link> ); }

这个封装好处很明显：外部链接时安全属性强制加好，内部路由时保持 Link 的预取能力，后续如果公司要接统一的埋点，只要在这个组件里加逻辑就行，不用全局搜索替换。

封装的时候我踩过另一个坑：给 Link 传onClick时，如果没有阻止默认行为，点击后 Link 自身跳转和 onClick 处理会叠加执行，有可能会触发两次导航。所以在封装里如果需要"先做自定义逻辑再跳转"，必须手动处理好调用时机，不要指望事件冒泡自动帮你管理这个顺序。

7.2 服务端重定向与中间件的配合

Link 和 useRouter 解决的都是在客户端怎么"走到另一个页面"，但服务端的拦截和重定向属于另一层逻辑。比如用户已经在客户端里看到一个指向/admin的 Link，但后台已经判断该用户没有权限，点击后应该怎么处理？链路是：

1. 用户点击 Link
2. Next.js 客户端尝试导航到/admin
3. 此时服务端中间件收到请求，检测权限
4. 如果无权限，返回重定向到/login或其他页面

在中间件里写重定向逻辑，能够保证即使有人绕过客户端直接输入 URL，也能被拦截。这部分是对 Link 体系的重要补充，因为 Link 本身并不会阻止访问，它只负责把你送到目的地，服务端权限校验是最后一道防线。

一个常见的误区是试图在 Link 上做权限判断，比如：

{hasPermission ? <Link href="/admin">进入后台</Link> : <span>无权限</span>}

这种做法把权限逻辑散落在各个渲染节点上，很容易漏掉某处；更严重的是只隐藏入口不挡直接输入 URL。所以我坚持：前端隐藏入口只是体验优化，中间件的服务端校验才是真正的安全护城河。

7.3 国际化与多语言导航的小技巧

如果你的项目需要 i18n（国际化），Link 的 href 通常会带上语言前缀，比如/en/about、/zh/blog。这块的处理要格外小心，因为一旦处理不好，跳转时语言参数会丢失，用户点一下就从中文跳到英文站了。

我比较推荐在封装层统一处理当前 locale，而不是每个页面手工拼：

// lib/i18nRoute.ts export function localizedHref(path, locale = "zh") { if (locale === "zh") return path; return `/${locale}${path}`; }

然后在 AppLink 内部，对内部路由再一次包装，这样在业务代码里永远只写/about这种纯路径，语言前缀只在封装层拼接。这个模式在公司内部多个项目里验证过，减少了大量因路由地址写错导致的沟通成本。

8. 常见问题与排查技巧实录

8.1 我没有做任何跳转，为什么 Network 面板有奇怪的请求

这是刚接触 Link 预取机制的开发者最常见的问题。页面加载完成后，Network 面板里能看到额外的 JS 文件、甚至服务端请求在自动发出。很多人第一反应是代码里有隐藏的 API 调用，排查了半天，其实可能只是页面中某处 Link 触发了预取。

排查方法很简单：打开 DevTools，在性能面板里记录加载过程；或者临时把页面上所有 Link 的prefetch设为false，再对比 Network 面板的请求列表。如果请求消失，说明预取问题；如果仍然存在，再继续查数据请求来源。

经验：不要轻易把预取全关掉，那等于放弃了 Link 最核心的体验优势。更好的方式是调整策略：视口外不影响首屏的链接、低频链接、需鉴权链接，单独禁用预取。

8.2 Link 包裹后点击没反应

这个问题我见过不少。排查时先确认渲染出来是不是真正的<a>标签：用 DevTools 检查 DOM 树，看元素标签名。如果渲染出来的是<div>或者别的标签，说明你的子组件结构有问题。常见原因是子节点传入了文本节点但没有包裹<a>：

// 不对，可能渲染出无意义块级元素 <Link href="/about">关于</Link> // 一般这样是可以的 // legacyBehavior 下必须有 a <Link href="/about" legacyBehavior> 关于 </Link> // 不对，因为 legacyBehavior 模式下必须有一个 a 子节点

如果你用的是legacyBehavior，必须显式包裹<a>：

<Link href="/about" legacyBehavior> <a>关于</a> </Link>

另一个可能原因是 href 传了undefined或空字符串，导致该链接无法点选。建议在渲染前打日志输出一下 href，排除数据未加载完成的情况。

8.3 页面跳转后滚动位置异常

如果你发现在页面切换后滚动到了奇怪的位置，或者没有回到顶部，大概率是 Link 的scroll属性没有按预期工作。默认情况下 Next.js 会执行滚动到顶部的行为，但如果你在外层 DOM 上设置了叠加滚动容器，Next.js 对window的 scrollTo 行为就无法影响那个容器。

这种情况需要手动处理：在页面组件里监听路由变化，调用容器的scrollTo(0, 0)；或者在 Link 上设置scroll={false}，再通过 useRouter 的push方法手动管理滚动位置。

另外还有一个隐藏逻辑：如果两个路由的滚动位置差得很远，可能是浏览器 的"滚动恢复"特性在起作用。浏览器会尝试保留相同 URL 的滚动位置，这个行为和框架无关，必要时在页面卸载时主动清理。

8.4 常见问题速查表

我把开发中最常遇到的问题整理成了一张表，方便你快速定位：

这里还要提醒一句：遇到 Link 相关的问题，优先从"最终生成的 DOM 标签"和"Network 面板里的请求"这两个维度排查，它们会透露绝大多数线索，比瞪着代码猜高效得多。

8.5 一个小技巧：用中间件调试导航链路

如果你在本地调试时想观察每次导航的意图，可以在中间件文件里加一行日志。中间件文件是middleware.ts（与app或pages同级）。在里面简单打点：

import { NextResponse } from "next/server"; import type { NextRequest } from "next/server"; export function middleware(request: NextRequest) { console.log("[nav]", request.nextUrl.pathname); return NextResponse.next(); }

这个方式能看到进入页面的完整路由轨迹，也能在中间件里临时加条件判断来模拟权限拦截或重定向。日志不要留在生产环境，调试完记得删掉。

9. 我个人的几个实操建议

最后聊几个只属于"踩过很多坑之后"的小心得。

第一，不要过度封装 Link，也不要完全裸奔。完全裸奔导致路由常量分散在每个页面，这会让将来改结构时痛不欲生；但为了封装而封装，加了一堆自定义属性和条件分支，又会让组件使用者读代码变得困难。我建议封装只做两件事：外部链接安全属性统一、业务路径统一管理，其他的保留原样。

第二，把预取策略当成性能预算的一部分来管理。项目里新增一个页面时，顺手评估一下：这个页面会被多少入口引用？用户点击概率有多高？如果概率不高，引用它的 Link 就加上prefetch={false}，这比事后性能优化容易太多。我见过太多项目上线后才发现首屏网络请求暴增，最后花整个迭代周期去拆无用预取。

第三，动态路由的参数命名一定要规范。如果你在文件结构上用了[id]，就保证所有代码里对它的引用都叫id，不要一会儿 ID，一会儿 id。碰到过团队成员在同一个项目里混用两种大小写，路由在开发环境正常运行，到了生产环境（因为数据内容不同）直接匹配失败，一查又是一小时。

第四，新版 Next.js 的版本升级会改变 Link 的一些行为属性，比如最开始提到legacyBehavior就是版本迭代的产物。我每年都会去翻一下官方更新日志里关于 Link 的部分，哪怕只是快速扫一眼，也能避免把旧写法的习惯带到新版本项目里。

Link 组件看起来就短短几行代码，背后的机制、边界、优化策略却是整个 Next.js 路由系统的重要缩影。把这些细节吃透，你再做页面跳转时就不会再凭感觉写，而是很清楚每一步正在发生什么，以及为什么要这么做。希望这些经验能帮你在项目里少踩几个坑，导航这块直接用得顺手。