unload事件中发送同步XHR请求的跨浏览器兼容性疑问

嘿，你的这个方案思路很务实，我来帮你拆解下其中的核心问题：

一、全浏览器无缝运行的可行性 #

你的方案在Chrome、Firefox和IE中测试表现稳定，但要做到所有浏览器无差异运行其实存在不少挑战：

• Chromium内核浏览器（Chrome、Edge等）：这类浏览器近年对unload事件中的同步操作限制越来越严格。即使你测试了无效链接、断网场景，但如果是有效且响应偏慢的请求，同步XHR的阻塞特性仍可能导致页面关闭延迟；部分新版本甚至会直接忽略这类同步请求，优先保证页面关闭的流畅性。
• 旧版Safari：Safari对unload事件的处理一直比较特殊，它可能会提前终止事件内的脚本逻辑，导致同步XHR根本无法完整发起。
• 移动端浏览器：多数移动端浏览器为了性能优化，会裁剪后台页面的unload事件执行逻辑，同步XHR的成功率会大幅下降。

二、调用abort()后的潜在页面等待风险 #

你在send()后立即调用abort()，看似能中断请求，但这里有个关键细节：
同步XHR的send()方法是阻塞主线程的——也就是说，send()执行期间，浏览器会等待请求的响应（或超时），之后才会执行abort()。如果目标服务器响应缓慢，或者网络状况波动，send()会持续阻塞主线程，导致页面无法及时关闭，甚至出现浏览器提示“页面正在等待操作完成”的弹窗。
即便abort()能中断请求，这个操作也是在send()的阻塞周期结束后才会触发，无法从根源上消除同步请求对页面关闭流程的干扰。

三、更稳妥的替代思路 #

如果Navigator.sendBeacon()的兼容性达不到要求，可以试试fetch API的keepalive选项：

window.addEventListener('unload', function() {
  fetch('http://localhost:8080/express/check', {
    method: 'POST',
    headers: {
      'Content-Type': 'application/json;charset=UTF-8'
    },
    body: JSON.stringify({}), // 根据业务需求传入请求体
    keepalive: true
  });
});

keepalive允许请求在页面关闭后继续发送，且是异步执行，不会阻塞主线程，兼容性比sendBeacon略广（支持Chrome 49+、Firefox 52+、Edge 14+）。如果需要兼容更老旧的浏览器，再考虑降级到同步XHR方案，但要做好异常场景的兜底处理。

内容的提问来源于stack exchange，提问作者Diogo Santos