eagerness参数必须配合where条件使用，否则moderate会作用于所有同源链接，极易引发内存暴涨甚至页面崩溃；基础规则需在中用声明source:"document"并指定eagerness:"moderate"，浏览器自动扫描同源链接并在悬停/聚焦约200ms后启动预渲染。
eagerness 参数必须配合 where 条件使用，否则 moderate 会作用于所有同源链接，极易引发内存暴涨甚至页面崩溃。
怎么写最基础的 moderate 预渲染规则
直接在 里放一段 <script type="speculationrules"></script> 即可生效，不需要任何 JS 初始化或监听事件：
<script type="speculationrules">
{
"prerender": [
{
"source": "document",
"eagerness": "moderate"
}
]
}
</script>
浏览器会自动扫描当前页面所有同源的 <a href></a> 链接，用户鼠标悬停或键盘聚焦后约 200ms 启动预渲染。注意：source: "document" 是关键，它让规则基于 DOM 而非硬编码 URL 列表，适合动态生成的 React/Vue 页面。
- 不要手动加
onmouseover或addEventListener，那会干扰浏览器原生去抖逻辑 - 该规则对跨域链接静默忽略，无需额外过滤
- 低内存设备（如部分 Android Chrome）可能自动将
eagerness: "eager"降级为moderate，但moderate本身不受影响
如何用 href_matches 精确控制预渲染范围
href_matches 是正则匹配路径的字段，不是 CSS 选择器，写错会导致误触发：
- 匹配商品页：
"href_matches": "/product/\d+"（注意双反斜杠转义） - 匹配文章列表分页：
"href_matches": "/articles\?page=\d+" - 错误示例：
"href_matches": "/*"—— 会匹配首页所有链接，包括页脚“隐私政策”，极危险 - 不支持通配符
*开头的相对路径，必须以/或协议开头，如"href_matches": "^https?://example.com/checkout"
真实场景中，建议先用 console.log([...document.querySelectorAll('a')].map(a => a.href)) 检查实际 href 值，再写正则。
为什么不能对 checkout 页面盲目用 eager
eagerness: "eager" 在链接一进入视口就触发，看似快，但对含副作用的页面风险极高：
- 支付页若在 prerender 阶段执行了
fetch('/api/order/start')，用户还没点就已创建订单草稿 - 登录页可能提前读取
localStorage或发起身份校验请求，导致状态污染 - 某些第三方 SDK（如广告、埋点）会在 prerender 时初始化并上报，产生无效曝光
- Chrome 会主动拒绝预渲染含
POST表单、meta refresh或敏感Content-Security-Policy的页面，eager不会绕过这些限制
真正该用 eager 的，只有那些确定性极高、无副作用、且资源轻量的跳转，比如文档站中“下一节”按钮指向的纯 Markdown 渲染页。
conservative 的真实触发时机和副作用
eagerness: "conservative" 在 mousedown 事件触发时启动预渲染，不是 click 也不是 mouseup：
- 用户按住按钮不放再拖走，预渲染已开始且不会取消
- 目标页若含大量计算或 API 调用，这部分开销会在用户按下瞬间发生，哪怕最终没松手
- 适合高代价但低频操作，如后台系统的“导出 Excel”跳转页，而非普通导航
- 如果页面依赖
document.visibilityState === 'visible'才执行逻辑，需检查是否在 prerender 阶段被绕过
最难的从来不是选哪个 eagerness 值，而是把 where 条件写准——它和 eagerness 共同决定“谁被预渲染”和“什么时候开始”，漏掉一个，优化就变成负优化。
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
