Navigator.sendBeacon 与 fetch keepalive：浏览器/标签页关闭时的请求可靠性及选型疑问

我来帮你把这些疑问理得明明白白的！

首先得把最核心的结论先摆出来：beforeunload 完全不适合用来发请求，它的设计初衷只是给用户弹个确认框（比如防止误关填了一半的表单），浏览器从没想过要保证这个事件里的请求能跑完——普通的XHR、fetch在这时候基本都会被直接中断，所以绝对不能依赖它做数据上报或请求操作。

接下来聊聊你提到的 sendBeacon：这个API就是专门为页面关闭/卸载时的可靠数据上报设计的！浏览器会把它的请求放进后台任务队列，就算页面开始卸载了，也会在后台悄悄把请求做完，而且完全不会阻塞页面关闭流程（不会让用户觉得页面卡着关不掉）。但它的局限性也很直白：只能用POST方法，没法自定义请求头、没法用GET/DELETE，也拿不到服务器的响应，适合那种只需要悄悄丢数据给服务器，不需要后续处理的场景。

然后是你最关心的 fetch + keepalive: true：这玩意儿绝对可靠，而且就是MDN官方推荐的、用来补sendBeacon短板的方案！当你需要用非POST方法（比如GET/DELETE）、自定义请求头，或者真的要处理服务器响应时，用它就对了。keepalive: true这个参数就是在跟浏览器说：“这个请求很重要，就算页面关了也得帮我做完”，浏览器会优先调度这类请求，不会像普通请求那样被直接砍掉，可靠性和sendBeacon是一个级别的。

不过用fetch keepalive的时候要注意几个小细节：

• 请求的总大小（包括请求头和body）有浏览器层面的限制，一般是64KB左右，超过的话可能会失败，sendBeacon也有类似限制，所以如果是大数据上报，可能得拆分或者换其他方式
• 如果你想处理响应，其实在页面卸载的场景下意义不大——因为页面已经要关了，后续的回调函数可能根本没机会执行，所以如果不是必须，尽量别依赖响应结果
• 跨域的话，和普通fetch一样，需要服务器配置好CORS允许你的请求

最后你问的：如果不用beforeunload，客户端层面有没有接近sendBeacon可靠性的方法？真没有了——sendBeacon和fetch keepalive是仅有的两个被浏览器专门优化过、能在页面关闭时保证请求完成的纯客户端API。websocket虽然能检测页面关闭，但它需要服务器配合，不算纯客户端方案，而且主要是用来做实时通信，不是专门的上报工具。

给你整个选型总结：

• 单纯上报数据，不需要自定义请求：用sendBeacon，简单又靠谱
• 需要非POST方法、自定义headers、或者处理响应：用fetch(url, { method: 'GET', keepalive: true, ...其他配置 })，可靠性拉满

备注：内容来源于stack exchange，提问作者klvs