用Safari传个大文件，传着传着就断了——这事你遇到过没？而且不挑网速、不挑服务器，偏偏就是浏览器自个儿在较劲。

说白了，这不是网络问题，也不是服务器出BUG。根子在WebKit引擎和macOS底层机制之间的设计冲突上。具体怎么回事？往下看。

内存映射与系统压缩机制冲突

Safari（基于WebKit）对付大文件时，有个习惯：把文件内容直接映射到内存里，再分片处理。尤其是超过100MB的视频或压缩包。

这招本身没问题，但macOS的内存压缩机制不这么想。它一看内存被占了大块，就判定“压力过载”，然后二话不说把WebContent渲染进程给干掉了。

结果就是：要么页面白屏，要么弹个“WebContent意外退出”的提示，要么上传进度卡住后直接断连。听起来像个误会，但每次发生都是真真切切的传输中断。

JavaScript上传路径特别脆弱

多数崩溃场景跟前端代码直接相关。尤其是用FileReader.readAsArrayBuffer()或Blob.slice()手动读取并上传的方式。

这些API干的事是频繁分配和释放内存，而Safari对这类操作的垃圾回收机制又总是慢半拍。临时对象越堆越多，最终被系统强制清理——上传自然就挂了。

• 拖拽上传、JS SDK分片上传、带进度条的自定义上传组件，这几个都属于高风险路径。
• 反而是原生
  提交最稳——它绕过了JavaScript的内存操作，由浏览器内核直接对接HTTP协议栈，稳定性高出一大截。

后台缓存残留干扰后续上传

没传完的大文件会在~/Library/Caches/com.apple.Safari/下留下损坏的临时磁盘映像。下次你传同名文件时，Safari可能自作聪明地去复用这些残块，结果就是连接异常中断或校验失败。这个坑挺隐蔽的，但一旦踩上，重复上传都很难成功。

WebKitMemoryPressureRelief开关误触发

macOS Sequoia系统里默认开了个叫“WebKitMemoryPressureRelief”的优化。本意是帮浏览器腾内存、保系统稳定，但实际执行起来有点过头——它会把正常的上传流程也当成“压力事件”来处理，时机一到就直接切断连接。好心办坏事，说的就是它。

传统上传通道被禁用

新版Safari默认改用Fetch API的流式上传方式。这玩意儿虽然能反馈实时进度，但对大文件的容错性很差。只要网络抖动一丁点，或者服务端响应稍微慢半拍，就容易触发超时断连。

而传统的表单同步提交虽然不显示进度条，但稳如老狗——只是用户看不到实时反馈，体验上差了那么一点。

基本上，原因就这些。

《夸克》非常好用的免费AI浏览器

下载APP查看