beforeunload事件唯一合法用途是用户关闭、刷新或跳转前弹出原生确认框，仅支持返回非空字符串触发提示，无法自定义文案或阻止卸载，且需页面存在有效用户交互才生效。

beforeunload 事件：只能拦人，不能干别的

这个事件的唯一合法用途，就是在用户点关闭、刷新、跳转前弹一个原生确认框。浏览器（尤其是 Chrome 从 2016 年起）已彻底禁止自定义弹窗文案、样式或逻辑控制——你返回的字符串只是给浏览器当提示文案用，最终显示什么由它决定。

常见错误现象：event.preventDefault() 单独调用不生效；event.returnValue = 'xxx' 忘记赋值或赋空字符串；在没用户交互的页面上注册后始终不触发。

• 必须满足“有效交互”才可能触发：比如用户按过键、点过按钮、拖过滚动条、输入过表单（但只聚焦输入框不算）
• 返回值必须是非空字符串，否则 Chrome/Firefox 直接忽略（Safari 更严格，可能完全不弹）
• 不能发起常规 fetch 或 XMLHttpRequest，因为事件回调结束后页面就进入卸载流程，异步请求大概率被中止
• 适合做的是：设置标记位（如 hasUnsavedChanges = true），然后在回调里简单返回提示语

unload 事件：收尸岗位，别指望它干活

unload 是页面真正开始销毁时触发的，此时 DOM 还在，但 UI 已冻结——alert、confirm、window.open 全部无效，用户也看不到任何反馈。

html-to-pptx-converter

使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。

下载

常见错误现象：在 unload 里写 fetch('/save') 却收不到请求；试图用 setTimeout 延迟执行清理逻辑；在 Safari 或新版 Chrome 中根本收不到该事件。

• 现代浏览器对 unload 的触发越来越保守：前进/后退缓存（bfcache）启用时，它压根不触发
• 无法阻止页面卸载，也无法影响用户行为，纯属“最后能碰一下内存”的机会
• 仅适合极轻量同步操作：清除定时器（clearTimeout）、解除事件监听（removeEventListener）、释放 Web Worker 引用
• 发请求？必须用 navigator.sendBeacon()，否则 99% 会失败；且不能依赖响应结果

替代方案比硬扛这两个事件更靠谱

靠 beforeunload 提醒 + unload 清理，已经不是现代前端的数据保底方案了。真实项目里更稳的做法是主动防御。

• 表单内容实时存到 localStorage，每次输入后 debounce 保存，关页再开也能恢复
• 关键操作（如编辑文档）加自动保存：用 setInterval 或 requestIdleCallback 定期提交，而不是赌用户不手滑
• 需要上报统计？优先用 navigator.sendBeacon() 替代 fetch，它专为卸载场景设计，异步但可靠
• 如果真要拦截离开，务必配合用户行为检测：只在 input、change、keydown 后才激活 beforeunload 监听，避免无意义注册

兼容性与调试要点

Chrome 和 Firefox 对 beforeunload 的限制逐年收紧，Safari 则在 bfcache 下直接跳过 unload。这些不是 bug，是浏览器主动做的安全收敛。

• 不要在开发工具 Console 里手动调用 location.reload() 测试 beforeunload —— 缺少用户手势，事件不会触发
• 移动端 WebView（尤其 iOS WKWebView）基本不支持 beforeunload 弹窗，得换思路（比如监听页面 visibilityState）
• pagehide 和 visibilitychange 是更可控的补充事件，适合做状态快照，但注意它们也不保证一定能执行完异步逻辑
• 所有卸载相关逻辑，必须假设“只有一瞬间可执行”，任何阻塞、等待、重试都不可行

实际项目里最常被忽略的一点：你以为用户关的是当前标签页，其实他可能只是切走了——beforeunload 不会触发，unload 更不会。这时候靠被动监听不如主动存档。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！