PDF.js 和 pdf-lib 在浏览器本地完成 PDF 合并

PDF.js 和 pdf-lib 让 PDF 合并完全在浏览器本地运行，不需要上传文件到任何服务器。这种方式既保护隐私，又把托管成本降到仅静态站点即可运行。大多数传统免费工具会把文件传到第三方服务器，带来暴露风险、尺寸限制和水印问题，而本地方案直接绕过这些限制。

本地处理切断第三方接触文件的路径

当用户选择两个或多个 PDF 文件后，整个合并过程发生在浏览器内存里，文件字节从未离开用户设备。这与传统在线工具形成鲜明对比，后者通常要求用户先上传文件。上传行为直接把敏感文档暴露给第三方服务器运营商。

信号明确指出，大多数免费 PDF 网站会悄悄上传文档，这带来多重风险。首先是隐私暴露，合同、医疗记录或财务报表一旦离开本地，就可能被服务器日志记录、备份甚至被第三方访问。其次是尺寸限制，许多在线服务对单个文件或总上传量设上限，超出即拒绝服务。最后是水印问题，免费版本常常在输出文件上添加广告或标识，影响正式使用。

本地合并方案一次性解决这三点。用户文件始终停留在浏览器沙箱内，开发者无法看到内容，服务器也无需存储任何数据。这对注重数据主权的个人和企业特别重要。浏览器本身提供的文件 API（如 FileReader）配合 WebAssembly 加速的库，使得读取和操作 PDF 成为可能，而无需任何后端参与。

这种切断路径的设计还意味着用户无需注册账号、无需同意隐私政策即可完成任务。整个流程在几秒内结束，输出文件可直接通过浏览器下载。相比之下，依赖服务器的方案往往还需要等待队列、处理延迟和潜在的数据泄露风险。

PDF.js 与 pdf-lib 在合并流程中的分工

PDF.js 主要负责读取和解析现有 PDF 文件。它由 Mozilla 维护，能在浏览器中渲染 PDF 并提取页面数据。在合并场景下，PDF.js 把用户选择的本地文件转为可操作的 PDF 文档对象，获取每一页的字节流和元数据。

pdf-lib 则承担实际的合并与修改工作。它支持创建新 PDF 文档，将来自不同源的页面复制并追加进去，同时保留原始的文本、图像和表单字段。两者配合形成完整流水线：PDF.js 先把本地文件加载为 Uint8Array，pdf-lib 再把多个文档的页面按顺序组装成一个新文档，最后生成可下载的 Blob。

整个过程无需服务器参与，所有操作通过 JavaScript 在浏览器主线程或 Web Worker 中完成。信号强调这一技术栈让开发者能构建纯前端应用，用户选中文件后，脚本自动完成读取、合并、导出三步，无需任何网络请求。

这种分工让代码保持简洁。PDF.js 处理解析的复杂性，pdf-lib 提供高级 API 来复制页面、设置元数据或压缩内容。开发者只需几行代码就能把两个 PDF 合并为一个，输出结果与专业桌面软件接近。

零服务器部署把托管成本压到最低

因为所有逻辑都在浏览器运行，后端完全不需要处理文件。开发者只需把 HTML、JavaScript 和必要的库文件部署到任意静态文件托管服务上即可。信号明确提到，这意味着托管成本可以降到零——只需一个静态站点，无论是 GitHub Pages、Vercel 还是 Netlify 的免费层都足以支撑。

传统 PDF 处理服务需要服务器接收上传、执行合并、再返回结果，这涉及存储、计算资源和带宽费用。随着用户量增长，成本会线性上升。而本地方案把计算负担转移到用户设备，开发者无需为每个合并任务付费。

对小型团队或独立开发者而言，这降低了进入门槛。一个简单的单页应用就能提供专业级功能，无需维护数据库、无需处理安全合规问题，也无需担心服务器被大文件攻击。更新功能时，只需重新部署静态文件，用户下次访问即获得最新版本。

这种架构还提升了可用性。用户即使在离线环境下（只要页面已加载），仍可使用核心合并功能，只要浏览器支持必要的 Web API 即可。

敏感文件处理场景下的真实落地价值

法律事务所合并合同附件、财务部门汇总报表、个人用户整理医疗记录时，隐私是首要关切。本地合并方案让用户无需把这些敏感文件托付给未知的在线服务，从而显著提升信任度。

信号指出，上传行为本身就构成隐私风险，尤其当文件包含个人身份信息或商业机密时。许多企业内部政策明确禁止将敏感文档上传到第三方平台。本地方案直接满足这类合规要求，符合 GDPR、HIPAA 等法规中关于数据最小化处理的原则——数据始终留在用户控制范围内。

用户信任也因此改变。过去用户对免费 PDF 工具持怀疑态度，因为不知道文件会被如何存储、是否会被用于训练模型或出售。现在他们可以验证整个过程发生在本地，甚至可以审查开源代码。这对需要频繁处理保密文件的专业人士而言，是实质性的工作流程改进。

浏览器性能与文件大小的实际边界

尽管本地处理优势明显，但浏览器环境仍有性能限制。目前方案适合中等大小的文件，典型场景是几个不超过 50 页的 PDF 合并。文件过大或页面数量过多时，内存占用会显著上升，浏览器可能出现卡顿甚至崩溃提示。

信号未详细给出具体性能数据，但明确这类工具运行在用户机器上，因此结果取决于设备配置。低端笔记本或移动设备在处理上百页高分辨率 PDF 时，合并时间会明显延长。pdf-lib 在复制页面时需要解析和重写 PDF 结构，这属于 CPU 密集型操作。

另一个边界是并发限制。浏览器对同时打开的文件句柄和内存分配有上限，尝试合并十个以上大型文件容易触发异常。目前还没有提到自动分块或流式处理机制，这意味着用户需自行控制输入规模。

开发者在使用时需考虑这些现实约束，可能通过添加进度提示或文件大小校验来改善体验，但根本限制仍来自浏览器沙箱和 JavaScript 单线程特性。

可直接复用的代码结构与扩展方向

核心实现通常从 input 元素获取文件列表，用 FileReader 转为 ArrayBuffer，再通过 PDF.js 的 getDocument 加载每个文件为 PDF 文档实例。随后使用 pdf-lib 的 PDFDocument.create() 创建目标文档，循环调用 copyPages 把源页面复制过来，最后序列化为 Uint8Array 并生成下载链接。

完整代码结构大致如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

function mergePDFs(files) {
  const pdfDocs = await Promise.all(files.map(file => loadPDF(file)));
  const merged = await PDFDocument.create();
  for (let doc of pdfDocs) {
    const pages = await merged.copyPages(doc, doc.getPageIndices());
    pages.forEach(page => merged.addPage(page));
  }
  const bytes = await merged.save();
  download(new Blob([bytes]), 'merged.pdf');
}

信号强调这一示例展示了如何完全在浏览器完成任务。基于此，扩展方向包括集成 Web Crypto API 对输出文件进行 AES 加密；利用 pdf-lib 的页面操作 API 实现页面重排、旋转或删除；甚至添加 OCR 预处理（结合 Tesseract.js）来提升扫描件质量。

进一步还可以开发拖拽界面、批量处理预览、主题切换等前端功能，使其成为完整离线工具。所有扩展均保持零服务器特性，持续享受隐私和成本优势。

这类工具正在改变在线办公的局部生态，尤其在数据安全要求日益严格的今天。它证明许多传统需要后端的任务，完全可以通过现代 Web 技术在客户端解决。

参考来源