PDFMergeNext 隐私设计白皮书 / PDFMergeNext Privacy Design Deep Dive
更新于 2026-08-09 · 阅读约 7 分钟 / 7 min read
1. 核心原则：文件不出设备
隐私设计的第一个决定是架构性的：把处理放在哪一端。在线工具把 PDF 上传到服务器再处理， 意味着文件内容经过第三方网络与磁盘——即使服务商不读取，传输与存储本身就是风险面。 PDFMergeNext 选择把全部处理放在浏览器本地：读取、解析、合并、写出，都在你的设备内存里完成。
- 无上传接口——代码里不存在把文件内容发往服务器的路径
- 无服务器存储——没有文件存储、没有合并历史、没有账号体系绑定文件
- 无第三方处理——不调用云端 PDF 处理 API，全程本地
2. 技术实现：本地处理的架构
具体来说，合并链路是这样跑的：选中的 PDF 通过浏览器 File API 读入内存， PDF.js 负责解析页面结构与渲染预览；排序、删除、合并这些操作全部作用于内存中的页面对象； 最后用 Blob 与 URL.createObjectURL 生成并触发下载。网络层面没有请求发出， 唯一可能的外部调用是加载工具自身的静态资源（页面、脚本），与你的文件内容无关。
这也是为什么离线也能用：工具本身是静态站点，缓存后就完全断网可用， 文件处理不依赖任何后端。想深入看离线与在线边界，可参考我们之前的离线合并边界分析。
3. 日志与数据策略：什么被记录
诚实交代：站点会运行基础的访问统计（页面浏览、来源、设备类型等匿名指标）， 用于了解工具是否好用。这些统计不含文件名、文件内容、合并参数或任何可还原文件的信息。 我们刻意不记录的内容包括：合并历史、文件哈希、文件大小分布（细粒度）、IP 与文件的关联。
- 记录：匿名访问统计（页面、来源、设备）
- 不记录：文件内容、文件名、合并历史、可还原文件的任何信息
- 存储：PDF 内容零存储，任务结束后内存即释放
4. 与在线工具对比：差异在哪
| 维度 | 在线合并工具 | PDFMergeNext（本地） |
|---|---|---|
| 文件流向 | 上传到服务器 | 不出设备 |
| 服务端存储 | 多数有临时存储 | 无存储 |
| 断网可用 | 不可用 | 缓存后可用 |
| 文件大小上限 | 受服务器配额限制 | 受本机内存限制 |
结论很直接：如果文件里有合同、证件、财务报表这类敏感内容，本地处理是唯一不需要 "信任服务商承诺"的方案，因为文件压根没有离开你的设备。
5. 诚实的安全边界
隐私设计不回避做不到的事。两条边界说清楚：
- 加密 PDF——需要密码才能解密，解密在本机完成。密码本身由你持有，工具不存储也不传输它。
- 浏览器环境——本地处理依赖浏览器沙箱。如果设备被恶意软件或浏览器扩展入侵，理论上页面内容可被读取。敏感场景建议在干净、无多余扩展的环境使用。
6. 常见问题 / FAQ
PDFMergeNext 会把我的文件上传到服务器吗？
不会。合并全程在浏览器本地完成，PDF 文件不离开你的设备，也没有任何上传请求。这是架构层面的设计，不是设置选项，所以不存在"默认上传"的隐患。
本地处理是怎么实现的？
核心是浏览器原生能力：PDF.js 负责解析与渲染，页面的合并、排序、删除都在内存里完成，最后通过 Blob 生成新文件。整个过程不依赖任何后端接口。
你们会记录合并历史或收集使用数据吗？
不记录文件内容，也不保存合并历史。站点只保留基础的访问统计（匿名、不含文件信息）用于了解工具使用情况，PDF 内容零存储。
本地处理在安全上有什么边界？
两条诚实说明：一是加密 PDF 需要你输入密码，解密在本机完成，但密码泄露风险由你持有密码的情况决定；二是浏览器扩展或恶意插件理论上可以读取页面内容，所以建议在干净的浏览器环境使用。