eagerness: "moderate" 必须配 where 条件，否则会无差别预渲染当前页所有同源 <a> 链接，导致内存暴涨甚至卡死；href_matches 不支持 /* 写法，应使用正则如 "^/product/\d+$" 并注意双反斜杠转义。
直接在 <head> 里加一段 <script type="speculationrules"> 就能生效，不需要 JS 监听、不依赖框架、不写事件绑定——但写错一行 JSON，就可能让浏览器疯狂预渲染首页所有链接，内存暴涨甚至卡死标签页。
为什么 eagerness: "moderate" 必须配 where 条件？
不加 where 的 {"prerender": [{"source": "document", "eagerness": "moderate"}]} 看似简洁，实则危险：它会让浏览器对当前页**所有同源 <a> 链接**（包括页脚“隐私政策”“联系我们”）都启动预渲染。Chrome 不会警告，只会在后台默默消耗 CPU 和内存，低端 Android 设备可能直接崩溃。
- 必须用
where明确圈定范围，例如只处理带data-track="next"属性的链接：{"where": {"selector": "a[data-track='next']"}} - 或按路径匹配商品页：
{"where": {"href_matches": "^/product/\d+$"}}（注意双反斜杠转义） -
href_matches不支持*开头的相对路径，"/*"是典型错误写法，会误中首页全部链接
prefetch 和 prerender 到底该选哪个？
别一上来就全上 prerender。它会真实执行目标页 JS、发起 API 请求、触发第三方 SDK 初始化——如果目标页含支付逻辑或登录校验，预渲染阶段就可能创建无效订单或污染本地状态。
-
prefetch：只下载 HTML/JS/CSS 到缓存，不解析不执行，适合分页、分类页等轻量跳转，兼容性更好（Firefox 也支持prefetch规则） -
prerender：完整渲染+执行，点击即显，但仅限内容稳定、无副作用、同源、无需登录态强校验的页面（如文章页 → 下一篇） - 推荐分层：先全局
prefetch打底，再对核心路径（如/checkout）单独加prerender，两者可共存于同一段 script 中
登录态和埋点怎么不崩？
预渲染时，目标页 JS 真实运行，但此时页面尚未激活——document.prerendering 为 true，且 Cookie 可用，但某些鉴权逻辑（如读取 localStorage 或调用 fetch('/api/user')）若没判断状态，就会失败或白屏。
立即学习“前端免费学习笔记（深入）”；
- 登录态透传：确保目标页 JS 在执行前检查
document.prerendering === false，关键请求延后到激活时刻 - 埋点上报：必须监听
prerenderingchange事件，或在document.prerendering === false时才触发，否则一次点击产生多次曝光 - 敏感操作拦截：用
{"not": {"href_matches": "*logout*"}}排除注销链接，避免预渲染时意外登出
最易被忽略的一点：Chrome DevTools 的 Preloading 面板能实时看到哪些规则被触发、哪些被取消及原因（比如“CPU 被限速”“跨域被拒”），但这个面板默认不打开——不主动去看，就永远不知道你写的规则到底有没有真起作用。
