body标签上的onbeforeunload属性不支持异步操作，因其为同步事件钩子，浏览器不等待Promise或AJAX响应，仅依据返回值或event.returnValue决定是否弹窗提示。
直接说结论：body 标签上的 onbeforeunload 属性无法支持异步拦截，所有试图在其中发起请求、等待响应、再决定是否弹框的逻辑都会失败——浏览器不等你，它只看返回值或 event.returnValue 是否存在。
为什么 body.onbeforeunload 不能做异步操作
这个属性本质是同步事件钩子，触发时机极短：用户点击关闭/刷新/跳转的瞬间，浏览器就要求你立刻给出“要不要拦”的答案。它不会为你暂停卸载流程，也不会等待 Promise resolve 或 AJAX 回调。
常见错误现象包括：
- 写了
fetch('/api/check')或await api.save()，但弹窗照常出现或根本不出现 - 控制台报
Uncaught (in promise) TypeError: Failed to fetch，因为页面已销毁，网络栈被回收 - 部分用户没看到提示，尤其是快速连续操作（如 Cmd+R → 立即点地址栏）时，事件甚至没来得及绑定
根本原因不是代码写错，而是浏览器规范强制限制：该事件处理函数必须在微任务队列清空前完成执行，且不允许任何异步副作用。
body 上写 onbeforeunload 和 window.addEventListener("beforeunload") 有啥区别
表面都是注册监听，但行为差异影响实际部署：
-
<body onbeforeunload="return confirmMsg()">：HTML 属性方式，仅支持字符串返回值，无法访问event对象，也无法做条件判断（比如只在表单脏时才提示） -
window.addEventListener("beforeunload", handler)：JS 方式，能读取当前状态（如formIsDirty），可动态设置event.returnValue，也方便后续移除（removeEventListener） - 兼容性上，IE8+ 都支持属性写法；而
addEventListener在 IE9+ 才稳定，旧项目若需兼容 IE8，只能用window.onbeforeunload = function() {...}
注意：body 属性写法在 Vue/React 等框架中基本无效——模板编译后它不会挂到真实 body 元素上，而是丢在虚拟 DOM 里，压根不触发。
真正可行的“准异步”策略：把检查提前到用户交互阶段
既然卸载时不能异步，那就别等到那一刻。核心思路是：把耗时检查（如权限校验、草稿存在性、服务端锁状态）挪到用户开始编辑、点击按钮、输入文字等可感知的交互时刻完成，并缓存结果。
- 监听
input、change、click等事件，在第一次交互后立即调用checkDraftStatus()并保存布尔值到sessionStorage或组件 data 中 -
beforeunload处理器只做同步判断：if (draftChecked && draftHasUnsaved) return "数据未保存" - 对需要强一致性的场景（如多人协作编辑页），前端在交互时发请求获取锁状态，成功则设
canLeave = true；失败则禁用提交按钮并提示，此时beforeunload仍按需拦截
这样既绕开了卸载时的异步限制，又保证了提示逻辑与用户真实意图一致。漏掉交互就无检查？那本来就不该拦——用户只是打开页面看了眼就关掉，不该触发业务侧资源占用逻辑。
容易被忽略的 Chrome 行为细节
Chrome 60+ 起，如果用户从未与页面发生任何交互（无点击、无键盘输入、无滚动），beforeunload 在点击浏览器「后退」「刷新」按钮时会被静默忽略——不弹框、不执行 handler、也不报错。
- 这意味着：纯展示页 + 直接点刷新，你的
onbeforeunload彻底失效 - 但
Cmd+R或F5仍会触发（因系统级按键事件被视为交互） - 解决办法不是硬扛，而是接受这个事实：没交互 = 没业务状态变更，本就不该拦。重点保障有操作用户的体验即可
最复杂的点从来不是怎么写 handler，而是如何定义“值得拦截”的状态边界——它必须可检测、可缓存、可撤销，且和用户真实动作对齐。否则，写得再“异步”，也只是在浏览器的卸载铁律前徒劳打转。
