大文件处理 · Large Files
大文件 PDF 合并：500MB+ 策略 / Large PDF Merge: 500MB+ Strategies
500MB 以上的 PDF 合并失败，绝大多数不是工具不行，而是内存撑不住。这篇讲的是实际处理顺序：判断瓶颈、先压缩后分批，最后给一份能反复用的排查清单。
阅读约 6 分钟 · 6 min read
一句话结论
大文件 PDF 合并 失败的根因通常是内存峰值，不是工具能力。先压缩源文件，再按 50 至 100 页分批，绝大多数 500MB 场景都能在浏览器本地跑完。
Large PDF merge failures above 500MB come from memory peaks, not from tool limits. Compress the sources first, then batch them 50 to 100 pages at a time, and most 500MB jobs finish locally in the browser.
500MB 以上 PDF 的真实瓶颈 / Where the bottleneck sits
PDF 不是一整块数据，它由对象表、页面树、字体、图片流和交叉引用表组成。解析器要先把这些结构读进内存才能重排页面，所以磁盘上的 500MB 和内存里的 500MB 完全是两回事。
| 文件特征 | 500MB 时典型峰值 | 主要占用来源 |
|---|---|---|
| 纯文本扫描件（已 OCR） | 600MB 至 900MB | 页面树 + 字体对象 |
| 高分辨率图片型 PDF | 1.2GB 至 2GB | 内嵌图片流解压 |
| 矢量图 + 透明图层 | 1.5GB 以上 | 图形状态栈 + 混合模式 |
| 加密或带数字签名 | 额外 200MB 至 400MB | 解密缓冲 + 证书链 |
浏览器还有自己的天花板：Chrome 在 64 位系统上单标签页通常能用到 2GB 到 4GB，Safari 更保守，大约 1GB 到 2GB。超过这个范围，页面不会报错，只会白屏或者被系统回收。
Watch the memory curve during a merge. A smooth climb means streaming reads are working. A staircase pattern means whole files are being pulled in at once.
合并前先瘦身：压缩能让 500MB 变成 80MB
一个 500MB 的扫描件 PDF，里面的图片往往是 300 甚至 600 DPI 的无压缩位图，实际阅读只需要 150 DPI。压缩之后文件通常能降到原来的 15% 到 30%，合并难度会下降一个数量级。
- 先在浏览器本地压缩每一个源文件，不上传、不留副本
- 检查压缩后的页面顺序和书签是否还在
- 再把压缩版本按顺序合并
- 最后保留一份未压缩的原件归档
详细做法见 PDF 本地压缩教程。这一步做完，后面的分批策略通常就不必用了。
分批合并：500MB 文件该怎么拆 / Splitting into batches
如果压缩后仍然超过 300MB，或者文件本来就不能压（比如矢量图纸），就走分批路线。核心思路是把一次性加载全部文件换成加载一批、合并一批、释放一批。
- 每批控制在 50 到 100 页，单批内存占用通常不超过 300MB
- 拆完之后按 01、02、03 的数字前缀命名，避免排序错乱
- 先合并前两批得到中间结果，再用中间结果去接下一批，而不是最后一次性合并几十批
- 每一批合并完成后立刻下载，不要全留在标签页里
文件数量特别多时，命名与排序另有讲究，对照 PDF 批量合并 100 个文件 里的清单。
浏览器本地合并 vs 桌面命令行
| 维度 | 浏览器本地合并 | 桌面命令行（qpdf / pdftk） |
|---|---|---|
| 文件是否外传 | 不出设备 | 不出设备 |
| 500MB 处理稳定性 | 受浏览器内存上限约束 | 依赖系统内存，通常更宽松 |
| 上手成本 | 拖入即可 | 需要装环境、记参数 |
| 断点续做 | 刷新页面即重来 | 脚本可重跑单批 |
涉及合同、病历、财务凭证这类内容时，本地处理不是偏好问题而是要求。PDFMergeNext 把解析和重排都放在浏览器里完成，文件从不离开设备，逐层拆解见 零上传 PDF 工具原理解析。
500MB 合并失败的排查清单 / Failure checklist
- 关闭其他标签页和占用内存的软件，尤其是视频会议和云盘同步客户端
- 换成 Chrome 的无痕窗口，排除扩展注入带来的额外内存开销
- 确认磁盘剩余空间大于待合并文件总大小的 3 倍，临时缓冲会写盘
- 把源文件从网络驱动器复制到本地磁盘，网络盘的读取延迟会拖长内存占用时间
- 单次只合并 2 到 3 个文件，而不是一次拖入 20 个
- 合并前先压缩，这一步能解决大约七成的失败案例
内存层面的机制，包括分块处理、Web Worker 和 Streams API 各自解决什么问题，写在 大文件 PDF 合并的浏览器内存策略。
现在就处理你的大文件
pdfmergenext.shop 在浏览器本地完成解析、重排和输出，500MB 级别的文件不经过任何服务器。拖进去，按上面的顺序先压缩、再分批，剩下的交给工具。
开始合并大文件 →常见问题
500MB 的 PDF 能直接在浏览器里合并吗？
可以，前提是单文件压缩后低于 300MB，或者按 50 至 100 页分批。未压缩的原始扫描件建议先压缩再合并。
Can I merge a 500MB PDF directly in the browser?
Yes, provided the compressed file stays under 300MB or you split it into 50 to 100 page batches. Raw uncompressed scans should be compressed first.
合并进度卡在 90% 不动，是失败了吗？
通常不是。最后阶段在写交叉引用表和重建页面树，大文件这一段可能持续一两分钟，期间内存占用不会有明显变化。
为什么合并出来的文件比两个源文件加起来还大？
字体子集没有被复用，或者两批图片的色彩空间不一致导致重新编码。先在压缩步骤统一到 sRGB 能明显缓解。
分批合并会丢书签或表单填写内容吗？
书签一般会保留，交互式表单字段在多次重排后可能失效。填写过的表单建议先导出为静态页面再合并。