上传时浏览器崩溃？稳定传输的解决方案

上传中途浏览器崩溃，原因几乎总是标签页的内存压力。Chrome 会杀掉私有内存超过约 2—4 GB 的标签页，而一个把 10 GB 文件整个加载进单个 Blob 对象的传输服务，会轻松突破这个上限。解决方法：选用通过 File API 的 slice() 方法分块流式传输文件的服务（多数现代服务都这么做），上传前关掉所有其他标签页，禁用会挂钩 fetch/XHR 的扩展程序，并在插电的桌面机而非靠电池运行的笔记本上上传。Firefox 在处理大型 File API 上传时，内存压力通常比 Chromium 小。

为什么浏览器会在上传时崩溃

两个架构现实发生了碰撞。第一，每个浏览器标签页都是独立进程，有自己的内存上限——Chrome 在 64 位系统上每个渲染进程约 4 GB，超出后 OOM Killer 介入。第二，在 JavaScript 中上传文件的最简单做法是把整个 File 对象直接放入 fetch 请求体，浏览器往往会在发送前尝试将其完整缓冲进内存。

设计良好的传输服务绝不这样做。它用 File.slice(start, end) 为每个 5—20 MB 的分块生成一个 Blob，上传该分块，然后释放内存。无论文件多大，内存占用始终维持在大约 分块大小 × 并发数 个字节以内。

如果上传在 500 MB 进度时正常，到 2 GB 时标签页变灰，说明服务在发送之前加载了整个文件。换一个服务或换一种方式。

激进地关闭其他标签页

Chrome 的内存压力是系统级共享的。另一个标签页在播放 4K YouTube，第三个打开着 Figma，第四个运行 Notion 各占 800 MB，加在一起压力很大。8 GB 内存的笔记本开着 12 个标签页上传 10 GB 文件，是在玩火。

开始大文件上传前，彻底退出 Chrome，只打开传输服务的标签页重新启动。macOS 活动监视器或 Windows 任务管理器应该显示浏览器在这一个标签页下的内存使用量远低于 2 GB。

禁用扩展程序

广告拦截器、隐私扩展、密码管理器和网络分析工具（uBlock Origin、Privacy Badger、LastPass、HTTP Toolkit）都会注入网络请求。多数情况下没有影响。但某些代码过时的扩展，尤其是那些为了检查请求体而缓冲它的扩展，会破坏流式上传并撑爆内存。

用无痕窗口测试（默认禁用扩展）。如果上传在无痕模式下顺利完成，扩展程序就是问题所在。一个一个启用来找出罪魁祸首。

GPU 较弱时禁用硬件加速

搭载老款 Intel UHD 620 或同类集成显卡的旧笔记本，有时会因为同时渲染进度条更新和处理文件读取缓冲区而崩溃。在 Chrome 的"设置 > 系统 > 使用硬件加速模式（如果可用）"里关掉它。这会损失一些整体流畅度，但能稳定内存受限系统上的大文件上传。

同样，禁用 Chrome 的"节省内存"模式——这个功能可能在内存压力下中途驱逐标签页。固定该标签页，或明确将其排除在节省模式之外。

超大文件改用 Firefox

Firefox 历史上在 File API 的内存预算管理上比 Chromium 更严格。对于反复让 Chrome 崩溃的 10 GB 上传，Firefox 通常能不声不响地完成同一个任务。在实现良好的服务上差异不大（两者都能很好地处理分块流式传输），但在实现欠佳的服务上，Firefox 的保守内存模型更能兜底。

macOS 上的 Safari 在大文件上传方面也很可靠，但需注意 iOS Safari 会主动终止后台标签页。

固定标签页，保持前台运行

后台标签页在内存压力下最先被驱逐。保持上传标签页处于前台，不要切换到另一个窗口 30 分钟后回来发现标签页已重新加载。Chrome 被"丢弃"的标签页重新加载后显示灰色占位符，其中正在进行的上传就此结束。

macOS 使用 caffeinate -s，Windows 在上传期间禁用节能睡眠。笔记本进入睡眠会关闭 WebSocket 和 XHR 连接，并非所有服务都能干净地从中断处恢复。

在插电状态下上传，不要靠电池

靠电池运行的笔记本会积极限制 CPU 和内存。macOS 的"低电量模式"和 Windows 的"省电模式"都会降低后台任务优先级，对于一个正在进行 AES 加密和网络写入的浏览器标签页来说，意味着传输停滞。

插上电源，禁用省电模式。如果笔记本支持 CPU 性能配置（戴尔 Power Manager、联想 Vantage），在传输期间设置为"性能"模式。

开始前重启浏览器

Chrome、Firefox 和 Edge 在长时间使用后都会慢慢泄漏内存。连续开了两天、打开又关掉了 40 个标签页的浏览器，在你打开上传页面之前可能已经带着 2 GB 的僵尸内存。彻底退出（macOS 用 Cmd+Q，而不只是关窗口；Windows 右键任务栏图标 > 退出），然后重新打开。

分块大小与硬件配置的匹配

对于允许配置分块大小的工具（多数服务不允许，但 rclone 之类的 CLI 工具可以），更小的分块占用更少内存。5 MB 分块配合 4 个并发 worker，任何时刻的缓冲约为 20 MB；100 MB 分块配合 4 个 worker 则是 400 MB。在 4 GB 内存的机器上，差异很重要。

基于 Web 的服务会自动选择默认值，通常是每块 5—20 MB，这是合理的范围。但自定义脚本有时为了"更快"而默认更大的分块，在小内存机器上就会失败。

上传时用活动监视器监控内存

上传过程中，观察浏览器进程的内存占用。macOS 活动监视器：内存标签，按浏览器名称过滤。Windows 任务管理器：详细信息标签，按"内存（专用工作集）"排序。

健康的分块上传无论进度如何，浏览器内存保持在几百 MB 稳定不变。如果内存随上传进度线性增长（10 GB 文件传到 50% 时内存已用 5 GB），说明服务在缓冲所有内容，这是设计缺陷，换一个服务。

选择为大文件浏览器上传而构建的服务

一个设计良好的传输服务，应使用 Web Worker 池进行加密的分块上传，有界内存，并对失败分块显式重试。HexaTransfer 通过 Web Worker 用 File.slice() 读取文件，每块用 AES-256-GCM 加密，无论发送 50 MB 还是完整的 10 GB，浏览器内存始终不超过几百 MB——当浏览器已经在应对你一天里的所有其他任务时，这一点至关重要。

在 hexatransfer.com 上试试 — 免费、无需注册、最多 10 GB。