合并 PDF，而不把一切压成图像

“把这五份 PDF 合并一下”可能指两条流水线。一条把既有的页面对象拼进单个文件；另一条把每页打印成位图，再把图片打包成一份新 PDF。两者都产出一个附件，但只有前者保留可选中文字与锐利矢量。

结构合并到底做了什么

在 PDF123 上，合并 通过拼接每个文件的页面对象，把两份或更多 PDF 合成一份。服务端用空底座跑 qpdf，对输入施加 --pages：页面流是作为页面搬过去的，不是截图。嵌入字体、矢量与原有书签都跟着这些页面一起走。这条路径没有任何一步把页面栅格化成图像，原生数字合同拼接后仍可搜索与复制。

默认上传顺序就是输出顺序。HTTP 表单在同一个请求里接受重复的 fileInput 部分；批大小只受上传限制约束，没有“最多两份”的硬上限。可选的 sortType=byFileName 会在拼接前按文件名重排输入。各来源的书签可以保留；输入本身没有大纲树时，合并不会凭空造出完整大纲。

单文件上传就是对这份 PDF 的原样直通。两份及以上会变成一份 merged.pdf，其页面是按所选顺序拼接的结果。OpenAPI、MCP 与 pdfx merge 暴露的是同一个 op id，所以脚本和浏览器点击不会对“合并”这件事偷偷给出不同答案。

什么时候会不小心栅格化

有些“合并”流程会先导出成图像（传真网关、扫描应用、以屏幕分辨率打印成 PDF），或者在拼接前把注释压成位图。文件体积因此暴涨、可能得重新 OCR，放大后还能看到像素边缘。

源文件本来就是数字 PDF 时，优先用流合并。只有当输入是扫描件、没有可用文本时才用 OCR，并且记住这里的 OCR 返回的是 Markdown（text/markdown），不是带隐藏文本层的重新分层 PDF。先栅格化再 OCR，与合并原生数字文件是两条产品路径。

如果你要的是页面图像，那是转换作业（PDF 转图像），不是合并。两种意图混在一起，“合并”结果就会变成几兆字节的文档相册。结构合并后再做压缩仍能缩小流，但撤不掉你已经烤进去的栅格化。

合并不承诺什么

合并不统一页面尺寸，不跨文件统一字体，也不从零重建目录。它不会替你解密已加密的输入：源文件有密码保护时先解锁。它也不替代某些法院门户要求的 portfolio/package 容器格式，只产出普通多页 PDF。

这些限制和你用浏览器、REST、MCP 还是 pdfx 无关。这个 op 是刻意收窄的，好让输出对自动化保持可预测。如果你需要有序的多步作业（先合并，再加水印，再压缩），用 POST /api/v1/pipeline 传一个有序的 steps 列表，而不是发明第二个“智能合并”开关。

怎么跑

在浏览器里用 合并 PDF，或者向 POST /api/v1/general/merge-pdfs 提交重复的 fileInput 部分（开发者）。命令行：

pdfx merge a.pdf b.pdf -o merged.pdf

也可以打到你自托管或托管的 base：

pdfx --cloud --api-base "$API_BASE" --api-key "$KEY" merge a.pdf b.pdf -o merged.pdf

公网站上的匿名目录调用不需要 Key；Key 的意义在于稳定的自动化身份，以及给带门闸的自托管服务器做认证。同一个 op 怎么用 curl 和 MCP 调用，见同一操作，四种客户端。