onafterprint 和 onbeforeprint 不可靠，仅 Firefox 基本符合规范；Chrome 63+ 延迟或不触发，IE 反向触发，Safari/Opera 完全不支持；推荐用 matchMedia("print") 替代。
onafterprint 和 onbeforeprint 不能当作可靠的打印生命周期钩子来用，尤其在 Chrome 63+ 之后行为不一致、Safari/Opera 完全不支持，IE 更是反向触发——它在打印对话框弹出前就执行了。
onafterprint 在哪些浏览器里会“准时”触发
只有 Firefox 能基本按规范执行：onafterprint 在用户关闭打印对话框（无论点“打印”“取消”还是直接关窗）后触发。Chrome 63+ 声称支持，但实测中常延迟数秒甚至不触发，尤其当页面含 iframe 或使用了 window.print() 主动调用时。IE 的实现最误导人：它把 onafterprint 当作 onbeforeprint 用，在打印设置刚启动、对话框还没出现时就执行脚本。
- Firefox：相对最可靠，但需注意页面未聚焦时可能被抑制
- Chrome：建议放弃依赖，改用
matchMedia("print").addEventListener("change", ...)捕获状态切换 - IE：必须配合
onbeforeprint使用，并手动加延时判断是否真进入打印流程 - Safari / Opera：无原生支持，
onafterprint属性会被忽略，不报错也不执行
onbeforeprint 触发时机比你想的更早
onbeforeprint 并不是“用户按下 Ctrl+P 后立刻触发”，而是浏览器决定要进入打印模式的最早节点——可能发生在用户点击菜单、快捷键触发、甚至 JS 调用 window.print() 的瞬间。这意味着你不能指望它来做“确认打印前弹窗”这种交互，因为此时打印对话框尚未渲染，用户看不到你的 alert() 或 confirm()。
- 它无法阻止打印流程（
event.preventDefault()无效） - 适合做的事：临时隐藏非打印元素（如按钮、广告）、切换 CSS 媒体样式、记录打印意图日志
- 不适合做的事：等待用户输入、发起异步请求、修改 DOM 后再等重绘完成
- 若用
addEventListener("beforeprint", handler)，注意 IE8 及更早版本不支持，必须降级为window.onbeforeprint = handler
用 matchMedia 替代 onafterprint 的实际写法
现代兼容方案是监听 matchMedia("print") 的 change 事件，它在打印预览开启和关闭时都会触发，且 Safari/Chrome/Firefox 全支持：
const printMedia = window.matchMedia("print");
printMedia.addEventListener("change", (e) => {
if (e.matches) {
// 进入打印模式：可隐藏导航栏、调整字体
document.body.classList.add("printing");
} else {
// 退出打印模式：恢复 UI，相当于 onafterprint 的位置
document.body.classList.remove("printing");
}
});
这个方案绕过了浏览器对 onafterprint 实现的分歧，也避免了 IE 的提前触发陷阱。唯一要注意的是：如果用户在打印预览中反复切换“打印”和“取消”，e.matches 会多次切换，所以恢复逻辑必须幂等（比如用 class 切换而非 appendChild/removeChild）。
两个属性共有的硬限制
onafterprint 和 onbeforeprint 都是 Window 级事件，只能绑定在 <body> 或 window 对象上，不能委托、不能冒泡、无法取消。它们不会在 iframe 子页面中触发，除非子页面自己声明了对应属性。更重要的是：当用户通过浏览器“另存为 PDF”或扩展程序静默打印时，这两个事件大概率不会触发——它们只响应原生打印对话框流程。
真正需要稳定感知打印状态的场景，别押注在 HTML 属性上；优先用 matchMedia + CSS @media print 组合，把逻辑收敛到样式层和轻量 JS 状态切换里。否则，你写的“打印后自动关闭窗口”代码，大概率只在 Firefox 里跑通一次，然后就被 QA 打回来重写。
