主流浏览器已基本废弃 link rel="prerender”，Chrome v110起默认禁用，Firefox和Safari从未支持，Edge同步弃用；实际仅可能做DNS预解析或TCP预连接，不加载HTML、不执行JS、不渲染DOM。

一个必须认清的现实是：如今想要在生产环境中依赖 link rel="prerender" 来实现页面预渲染，已经是一条走不通的路了。各大浏览器已集体为其亮起红灯。

为什么 link rel="prerender" 现在基本失效

这事儿得从浏览器的态度说起。早在Chrome v110版本，prerender 就已经被默认关闭，仅仅作为一项实验性功能苟延残喘。而Firefox和Safari这两位，更是从一开始就没打算支持它。至于基于Chromium的Edge，自然也是同步弃用。结果就是，你满怀希望加上的标签，浏览器要么直接忽略，要么仅仅施舍一点“怜悯”——只做一下DNS预解析或TCP预连接，核心的HTML加载、Ja vaScript执行乃至DOM渲染，一概免谈。

即便在那些曾短暂支持的版本里，触发条件也堪称苛刻：页面必须在最前台，CPU还得处于空闲状态，内存要足够充裕，而且目标页面通常要求同源（某些版本甚至强制HTTPS）。更令人沮丧的是，用户一个不经意的操作，比如切换标签页或者滚动一下当前页面，就能让正在进行的预渲染立刻中止。

最麻烦的或许还是调试。你在开发者工具的Network或Application面板里，几乎找不到预渲染请求的明确痕迹。这种“悄无声息”的特性，很容易让你产生“它好像生效了”的误判，从而浪费大量排查时间。

替代方案：用 link rel="prefetch" + 手动 hydrate 更可控

那么，路在何方？目前业界最广泛支持、也最可靠的路径，是转向 link rel="prefetch"，再配合前端的手动激活（hydrate）。这套组合拳拿到的效果，足以媲美甚至超过当年人们对 prerender 的期望。

具体怎么做？第一步，在关键的入口页面（例如首页的导航栏）中加入预取指令：

注意，这里的 as="document" 至关重要。如果省略，浏览器可能会把它当作普通资源处理，无法享受专为HTML设计的HTTP缓存流程。

接下来，可以加入一些更积极的交互预测。比如，当用户鼠标悬停（hover）或聚焦（focus）在某个链接上时，前端代码可以主动调用 fetch() 提前获取HTML内容。拿到内容后，既可以用 DOMParser 进行解析预处理，也可以悄悄地注入一个隐藏的