beforeunload事件唯一合法用途是用户关闭、刷新或跳转前弹出原生确认框，仅支持返回非空字符串触发提示，无法自定义文案或阻止卸载，且需页面存在有效用户交互才生效。
beforeunload 事件：只能拦人，不能干别的
这个事件的唯一合法用途，就是在用户点关闭、刷新、跳转前弹一个原生确认框。浏览器（尤其是 Chrome 从 2016 年起）已彻底禁止自定义弹窗文案、样式或逻辑控制——你返回的字符串只是给浏览器当提示文案用，最终显示什么由它决定。
常见错误现象：event.preventDefault() 单独调用不生效；event.returnValue = 'xxx' 忘记赋值或赋空字符串；在没用户交互的页面上注册后始终不触发。
- 必须满足“有效交互”才可能触发：比如用户按过键、点过按钮、拖过滚动条、输入过表单（但只聚焦输入框不算）
- 返回值必须是非空字符串，否则 Chrome/Firefox 直接忽略（Safari 更严格，可能完全不弹）
- 不能发起常规
fetch或XMLHttpRequest，因为事件回调结束后页面就进入卸载流程，异步请求大概率被中止 - 适合做的是：设置标记位（如
hasUnsavedChanges = true），然后在回调里简单返回提示语
unload 事件：收尸岗位，别指望它干活
unload 是页面真正开始销毁时触发的，此时 DOM 还在，但 UI 已冻结——alert、confirm、window.open 全部无效，用户也看不到任何反馈。
常见错误现象：在 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 更不会。这时候靠被动监听不如主动存档。 
