操作选择 · Merge or Split
PDF 合并 vs PDF 拆分：什么情况该用哪个 / PDF Merge vs Split: When to Use Each One
合并改的是文件数量，拆分改的是页码边界。确定交付终点是"一份"还是"几份"，第一步的选择就清楚了。
阅读约 7 分钟 · 7 min read
一句话结论
PDF 合并拆分这个问题，看一条就能定：你要改的是文件数量，还是页码范围。合并把多份合成一份，解决的是交付、归档、页码连续；拆分把一份按页码切成几份，解决的是体积上限、分发对象不同、只要其中几页。两件事都不重新绘制页面内容，所以“用完之后画质变差”多半是压缩那一步造成的，合并和拆分本身不背这个锅。
顺序同样有讲究：先合并定版，再按需拆分。反过来做，容易在拆完之后才发现漏了几页，再回头去源文件里翻。
Choosing between merging and splitting comes down to one question: are you changing the number of files, or the range of pages? Merging collapses several files into one and solves delivery, archiving and continuous page numbering. Splitting cuts one file at page boundaries and solves size caps, recipients who should not see everything, and requests for a handful of pages. Neither operation redraws the pages themselves, so when the output looks worse, the step that did the damage is usually compression sitting in between.
两者改的东西不一样 / What each one actually changes
合并改的是容器。你按最终阅读顺序排好 A、B、C 三份文件，工具按这个顺序把页面对象依次搬进一个新文件，页面一页不多一页不少，字体、矢量图形、已经压过的位图都原样带走。真正被改动的是文件级别的字段：标题只能留一份，书签要么重新排要么塌成一堆同名条目，具体取舍见 /blog/pdf-bookmark-merge-keep-outline。
拆分改的是页码边界。源文件不动，你给出一组页码范围，工具把落在每段里的页面复制成新文件。复制过去的还是原来那批页面对象，所以拆出来的第三份里的第十四页，和母版的第十四页是同一份数据。容易出问题的是跟着“整份文件”存在的东西：书签、封面、目录页、跨页的表格，最后只落在其中一个分片里。
Merging changes the container. You put files A, B and C into final reading order and the tool copies their page objects into a new file in that sequence. Nothing is added or dropped, and the fonts, vector graphics and already-compressed bitmaps come along unchanged. Splitting changes the page boundary instead: the source stays intact, you supply ranges, and each range becomes its own file holding copies of the original page objects. The awkward part is everything scoped to the whole document, since bookmarks, the cover, the contents page and tables spanning a spread end up living in one piece only.
判断对照表 / Side-by-side
七个维度摆在一起看，多数场合的答案在表的前三行就已经出现了。
| 判断维度 | 合并 | 拆分 |
|---|---|---|
| 改的是 | 文件数量，多变一 | 页码边界，一变多 |
| 页面内容 | 原样搬运 | 原样复制，不重绘 |
| 文件体积 | 累加，通常变大 | 按段切，每段变小 |
| 典型触发条件 | 交付一份正本、连续页码、归档 | 上传上限、分人发放、只要某几页 |
| 常见后遗症 | 体积过大发不出去 | 分片缺封面和目录、文件名乱 |
| 可逆性 | 可，按原顺序拆回去 | 重拼容易错序，最好一次做对 |
| 掉画质的原因 | 中间夹了压缩，不是合并本身 | 同上，压缩放在最后做一次 |
最后一行最常被忽略：合并和拆分都不压缩页面内容，体积变化来自页面的重新组合，画质受损几乎总是中间那次压缩造成的。
五种场合怎么选 / Which one fits the job
- 合同正文加附件加签署页，对方要一份连续编号的正本。合并。收件方需要的是一个文件、一套页码，这是最典型的场景。
- 扫描仪一次吐出六十页双面稿，中间还漏扫了一页。合并，但先用 Page Selection 把补扫那页插到正确位置，语法见 /blog/pdf-page-selection-1-3-5-syntax。
- 企业邮箱附件上限 10MB，成品 42MB。拆分，按章节切开分几封发，或者顺便整份压一次；压缩与合并的先后问题见 /blog/compressed-pdf-merge-quality-loss。
- 政府门户只收单个文件且不超过 5MB。两步都要：先合并确认内容齐全、页码连续，再拆到限制以下，别直接把没合过的原件扔上去。
- 报销只要发票那两页，其余不用交。拆分。用页码范围把需要的部分取出来，比整份上传后让对方自己找干净得多。
先后顺序 / The order to work in
两个动作的组合顺序，比单独选哪个更容易出错。下面这条路线适用于绝大多数场合，全程不超过五分钟。
- 先定终点：交付形态是一份还是多份，收件方有没有硬性大小限制
- 需要合一就先合并，一次成型，中间不要夹压缩
- 合并成品检查一遍页码和顺序，确认没有缺页也没有重复页，这一步就算定版
- 定版之后再拆，按章节或页码范围切
- 拆之前把书签和层级设好，页码范围才不会因为插入新页错位
- 拆分成品立刻按规则命名，别留一堆重名的下载名，规则见 /blog/pdf-naming-conventions-merge
- 母版单独存一份不动，成品放另一个文件夹
整个过程文件都留在本机，合并、拆分、检查都在浏览器里跑完，不需要先把合同传到别人的服务器上。大文件的内存策略见 /blog/large-pdf-merge-500mb，批量处理的做法见 /blog/pdf-batch-merge-100-files。
在 pdfmergenext.shop 先合并定版，再按页码范围拆分 →更多 PDF 合并拆分的判断细节见 /blog。
常见问题 / FAQ
合并后再拆，画质会掉吗？
不会。合并搬的是页面对象，拆分复制的也是同一批页面对象，字体和矢量图形都不重新编码。真正伤画质的是中间的压缩环节，所以对的做法是把压缩放到最后一步，只做一次。
60MB 的文件该先合并还是先拆分？
先看交付要求。收件方要一份完整文件，就先合并再处理整体体积；只要其中几页，就先按页码把那部分取出来，整份不用动。先确定终点长什么样，第一步自然就定了。
拆分后的文件会丢书签吗？
看工具。有的把整份书签原样复制给每个分片，有的直接丢掉。拆完随便开一个分片看看导航面板，缺了就按那一版的章节重建，比重新拆一遍省事。
页码范围可以一直复用吗？
不能。它指向的是当时那一份文件的页码，源文件中间插入或删掉页面之后，原来的范围就错位了。源文件每变动一次，重新确认一遍页码。
Does splitting a merged file hurt image quality?
No. Merging copies page objects and splitting copies the same objects again, so fonts and graphics stay un-reencoded. Compression is what costs quality, so keep it last and run it once.
Should I merge or split a 60MB file first?
Start from what has to be delivered. One complete file means merge, then deal with the total size. A few pages means pull those out with a range and leave the rest alone.
Do the split pieces keep their bookmarks?
It depends on the tool. Some copy the full outline into every piece and some drop it. Open one piece, check the navigation panel, and rebuild the tree for that piece if it is empty.
Can I reuse a page range?
Not safely. A range refers to positions in the file as it was at that moment, so inserting or deleting pages upstream shifts every number after it.