prerender2.0不依赖用户点击预测，而是由开发者主动声明；它基于mparch架构实现轻量预渲染，仅支持同源get页面，需结合路由守卫精准触发，并严格区别于prefetch和preload。
预渲染（Prerender2.0）不依赖用户点击行为预测
Prerender2.0 本身不包含用户行为建模或点击预测逻辑。它不分析历史点击流、停留时长或鼠标轨迹，也不调用机器学习模型来“猜”用户下一步点哪。浏览器只在明确收到 <link rel="prerender" href="/next-page/"> 指令后，才启动预渲染流程——这个动作必须由开发者主动声明，而非自动推断。
实际中，是否插入该标签、插在哪一页、指向哪个 href，才真正决定资源调度时机。常见做法是结合服务端埋点或前端路由守卫，在用户大概率进入某路径前（比如商品列表页中「加入购物车」按钮 hover 1s 后），动态注入 prerender 标签。但决策逻辑在业务层，不在 Prerender 机制内部。
Prerender2.0 的资源调度基于 MPArch 架构约束
它依赖 Chromium 的多页面架构（MPArch），即单个 WebContents 实例可管理多个不可见的 Page 实例。这种设计让预渲染开销大幅下降：不再像 Prerender1.0 那样为每个预渲染页新建独立进程和内存空间。
调度行为受以下硬性限制：
- 仅支持同源、GET 请求的目标页面（
href必须是完整 URL，不能带 fragment 或 query 参数过多） - 页面中若含
<script></script>执行、fetch()、WebSocket或localStorage写入，会触发降级为prefetch（只下载不执行） - 设备空闲、内存充足、网络非节流（如 Chrome 的
network.connection.effectiveType为4g或更好）是前提条件
与 prefetch 和 preload 的关键区别不能混用
三者语义和浏览器处理逻辑完全不同，错配会导致预期外降级或无效：
<link rel="preload"> 只提前加载单个资源（如字体、关键 JS），不触发 HTML 解析，也不影响导航；<link rel="prefetch"> 是低优先级后台下载，目标是未来可能访问的页面资源，不执行 JS、不构建 DOM；而 <link rel="prerender"> 是全页面模拟加载+解析+执行（除部分 API 外），目标是让用户点击后“零延迟跳转”。
容易踩的坑：
- 在非首屏区域写
prerender—— 浏览器会忽略（只对当前 tab 的主文档上下文生效） - 把
prerender和prefetch指向同一 URL —— 后者会被前者覆盖，但不会叠加效果 - 未监听
prerenderingchange事件就假设页面已 ready —— 实际可能被中断，需用document.prerendering判断状态
真实场景中需要配合前端路由做精准触发
纯静态 HTML 插入 prerender 标签意义有限。现代 SPA（如 React/Vue）必须在路由切换前判断下一路由是否值得预渲染，并动态注入标签。例如：
// React Router v6 中的典型模式
useEffect(() => {
if (nextPath === '/checkout') {
const link = document.createElement('link');
link.rel = 'prerender';
link.href = '/checkout';
document.head.appendChild(link);
}
}, [nextPath]);
更稳妥的做法是加一层守卫：只对用户停留 > 1.5s 且鼠标移向特定链接的页面，才触发 prerender 注入。否则大量无差别预渲染会浪费带宽、内存，反而拖慢当前页。
复杂点在于：Prerender2.0 不提供回调或完成事件，你无法知道它是否成功执行完 layout/paint，也无法捕获其中 JS 报错。所有调试只能靠 chrome://net-internals/#prerender 查日志，这点极易被忽略。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
