当网站接入Speculation Rules API实现预渲染后，不少基于jQuery的旧项目会出现一个隐蔽故障：页面看起来正常加载，但按钮点击、表单提交等交互完全没有反应。这种现象并不是jQuery本身有缺陷，而是预渲染机制改变了文档的生命周期，导致脚本在错误的时间绑定了事件。要彻底解决，需要先理解预渲染到底对DOM做了什么，再针对性调整事件绑定策略。
预渲染如何破坏jQuery的事件绑定
Speculation Rules API允许浏览器在空闲时根据规则提前获取并渲染下一个可能访问的页面，这个过程称为预渲染。预渲染的页面处于一个独立的Document实例中，用户真正点击链接时，浏览器会将该Document激活为当前页面，而不是重新加载。问题在于，如果jQuery的绑定代码在预渲染阶段执行，它操作的是预渲染文档里的DOM节点；而激活后，虽然页面内容视觉上一致，但部分实现中节点会被替换或重新关联，导致原先通过$(selector).on('click', handler)绑定的监听器随旧节点被丢弃。
很多项目把事件绑定写在$(document).ready()中，在预渲染时这个回调就会触发，因为预渲染文档也会走完整的解析与DOMContentLoaded流程。等用户进入页面，jQuery并不会再次执行ready，于是新文档上的元素没有事件。传统上我们认为ready只跑一次，但在预渲染场景下，一次是给预渲染文档跑的，对用户而言却是无效的。理解这一点，才能明白为什么简单的刷新或重复引入脚本往往无效。
另一个容易被忽略的点是，Speculation Rules API提供了pagereplace与activation相关的生命周期事件，例如pageswap和pagereveal。这些事件在标准制定中用于让开发者感知预渲染到激活的切换，但jQuery并没有内置对这些事件的处理。如果我们的代码不监听它们，就无法感知文档何时从预渲染变成可见激活状态，自然也就错过了正确的绑定时机。
使用事件委托避开节点替换问题
事件委托是最低侵入性的修复方式。jQuery的on方法支持把监听器绑在不变的祖先元素上，利用事件冒泡处理动态子元素。由于预渲染激活后，document或body这类顶层容器通常保持稳定，把点击委托给它们就能绕过子节点被替换的坑。下面代码展示用委托替代直接绑定：
// 不推荐：直接绑定，预渲染激活后可能失效
// $('.btn').on('click', function(){ alert('clicked'); });
// 推荐：委托到 document，兼容预渲染激活
$(document).on('click', '.btn', function(){
alert('clicked via delegation');
});
这种写法的原理是，无论.btn是哪个文档实例里的节点，只要它存在于document之下，点击事件冒泡到document时都会被同一处理函数捕获。即使预渲染文档的.btn被换掉，新节点的事件依旧能冒上来。它的优点是改动小，不需要感知预渲染生命周期，对老项目友好。
不过事件委托并非万能。如果页面中有大量不同选择器需要委托，或者某些事件不冒泡（如focus旧版），处理会复杂。另外委托层级过深可能带来轻微性能损耗，但在绝大多数业务页可接受。实践中建议统一在document或明确的稳定容器上做委托，避免在每个模块各自绑定。
监听生命周期事件做精准重绑定
对于必须直接绑定或需执行初始化逻辑的场景，可以利用浏览器暴露的预渲染生命周期。以pagereveal为例，它在预渲染页面被激活为用户可见页面时触发，此时绑定事件就能命中最终文档。下面示例演示结合jQuery与标准事件：
function bindButtons(){
$('.btn').off('click').on('click', function(){
console.log('active doc button');
});
}
if ('onpagereveal' in window) {
window.addEventListener('pagereveal', function(e){
if (e.view) {
bindButtons();
}
});
} else {
$(document).ready(bindButtons);
}
代码中先判断pagereveal支持情况，不支持时退回ready。在支持的环境下，预渲染阶段不会执行bindButtons，只有激活才跑，从而绑定到正确的节点。为了防重复绑定，我们在函数里先用off解绑同事件。这个方案比纯委托更可控，适合需要操作具体DOM、插件初始化的模块。
还可以配合MutationObserver监听body子节点变化，当发现关键容器被预渲染框架替换时触发重绑。虽然Observer本身有开销，但只观察少量属性时可忽略。综合来看，大型项目应以委托为主，生命周期事件为辅，既保证交互不丢，也照顾特殊组件。测试时务必用Chrome Speculation Rules调试面板确认预渲染发生，再验证点击是否生效，避免本地无预渲染导致误判修复成功。
兼容性与上线注意事项
Speculation Rules API目前主要在基于Chromium的浏览器中实现， Firefox和Safari尚未全面支持。这意味着我们的重绑定代码要有渐进增强思维：不支持预渲染的浏览器走原有ready逻辑不受影响，支持的浏览器通过新事件或委托获得修复。不要因为引入pagereveal判断而破坏旧环境，上面的特性检测已经体现了这一点。
上线前应在配置Speculation Rules的页面中加入日志，统计pagereveal触发率和绑定成功率。若发现某些jQuery插件内部自己绑了事件又没用委托，需要考虑用pageswap在离开前销毁或激活后重初始化。此外，预渲染会消耗额外内存，事件重绑定代码应保持轻量，避免在生命周期事件里做重排或同步大量DOM查询，否则可能抵消预渲染带来的速度收益。
最后提醒，Speculation Rules的JSON配置应只针对安全可预渲染的页面，避免把含表单态的页面误预渲染，否则即使事件修好，状态不一致也会引发其他bug。jQuery作为老库，在新技术下略显笨重，但通过上述事件委托与生命周期结合的方式，仍能在现代浏览器中平稳运行，不必急于全部重写为原生代码。
jQuerySpeculation_Rules_API事件重绑定修改时间：2026-08-14 10:09:37