客户端 PDF 处理：浏览器本地 PDF 工具如何工作

客户端 PDF 操作的端到端流程是：

1. 文件输入。用户把文件拖入 dropzone。浏览器给页面一个 File 对象（指向磁盘上文件的指针，不是字节本身）。
2. 读入内存。页面调用 file.arrayBuffer() 把字节读入页面内存中的 ArrayBuffer。这是文件字节存在于页面的唯一时刻；它们还不在任何 worker 中。
3. 校验。页面在做任何工作前检查文件类型（魔数、扩展名）和大小。无效文件在主线程快速失败，永不进入 worker。
4. 转移到 Web Worker。页面把 ArrayBuffer post 给 worker，使用可转移传输，使字节移动（而非复制）到 worker 的堆。主线程不再能访问该 buffer。
5. 在 worker 中处理。worker 调用 PDF 库（pdf-lib、PDF.js 或 WASM 编译的 qpdf/mupdf）解析并修改 PDF。这是重活，在主线程之外运行以免 UI 冻结。
6. 返回结果。worker 产生新的 ArrayBuffer（或 Blob）并 post 回主线程，同样作为可转移对象。
7. 作为下载提供。主线程把结果包装为 Blob，调用 URL.createObjectURL(blob)，并通过 <a download> 元素作为下载提供。对象 URL 在下载开始后被撤销以避免内存泄漏。

在这个流程中，文件永不离开设备。没有携带文件内容的 fetch、XMLHttpRequest、sendBeacon。页面发出的唯一网络请求是页面首次加载时的静态资产（HTML、JS、CSS、字体）。

客户端 PDF 工具建立在一小套浏览器 API 和一小套 JavaScript 库之上。每个做一件事。

• File API——File 和 Blob 接口。file.arrayBuffer() 把字节读入内存；new Blob([bytes], { type: 'application/pdf' }) 把字节打包用于下载。
• Web Workers——一个有自己堆的后台线程，无 DOM 访问。PDF 解析在这里运行以保持主线程响应。通信通过 postMessage；ArrayBuffer 可使用第二个参数转移（移动而非复制）。
• URL.createObjectURL / URL.revokeObjectURL——产生一个指向内存中结果的临时 blob: URL，使 <a download> 元素能将其作为下载提供。该 URL 必须被撤销否则会泄漏。
• pdf-lib——一个纯 JavaScript PDF 库，能创建、修改和重新保存 PDF。用于合并、拆分、旋转、水印、页面操作和元数据编辑。不支持加密（已知限制——见下）。
• PDF.js——Mozilla 的 PDF 渲染器，用于把页面渲染到 canvas（用于 PDF 转图像）以及解析 pdf-lib 无法读取的 PDF。
• WASM（可选）——用于把原生代码编译到浏览器中以接近原生的速度运行。qpdf 和 mupdf 可编译为 WASM；IXPDF 选择性地使用此路径处理 pdf-lib 无法完成的操作。
• CompressionStream——浏览器原生流式压缩 API（gzip、deflate）。对某些不附带 JS 压缩库的体积缩减路径有用。

PDF 解析是 CPU 密集且形状上同步的——你读字节、解码对象、跟随交叉引用、构建内存树。50 MB 的 PDF 解析可能需要数百毫秒，200 MB 的 PDF 可能需要数秒。如果这工作在主线程运行，页面在此期间被冻结：无动画、无滚动、无输入。浏览器可能显示"页面未响应"对话框。

把工作移到 Web Worker 解决了这个问题。主线程保持响应；worker 在后台咀嚼 PDF；页面显示进度指示器并在 worker post 结果时更新 UI。代价是 worker 无 DOM 访问，所以任何 UI 工作必须在结果返回后在主线程进行。

Worker 也有自己的内存预算。转移到 worker 的大 PDF 住在 worker 的堆中，而非页面的。这对非常大的文件很重要：worker 持有重 buffer 时页面可保持轻量，buffer 在 worker 完成时被释放。

当 ArrayBuffer 不带 transfer 被 post 给 worker 时，字节被复制——worker 得到自己的副本，主线程保留原件。对 100 MB 的 PDF 这意味着使用 200 MB 内存和可察觉的复制时间。

修复是转移列表：postMessage 的第二个参数。把 buffer 列入转移列表会把字节移动到 worker——主线程的引用被分离（零长度），worker 取得所有权。无复制，无翻倍内存。返回结果时使用同样的技巧。

这是一个在规模上很重要的细节。没有可转移对象，大文件的客户端 PDF 处理将不切实际。

客户端处理不是银弹。有些操作在今天浏览器中难以做好或不可能做好，诚实的工具会承认而非伪造。

• OCR。对扫描 PDF 的光学字符识别需要训练过的模型和大量 CPU。浏览器 OCR 存在（Tesseract.js），但质量远落后于桌面 Tesseract 或云 OCR。IXPDF 将 OCR 标记为 Research Required。
• PDF 加密（密码保护）。pdf-lib 尚不支持写入加密 PDF。添加它需要不同的库或 WASM 编译的 qpdf。IXPDF 的保护 PDF 工具是 Research Required。
• PDF 转 Word/Excel/PowerPoint。把 PDF 转为可编辑 Office 文件是一个布局重建问题，需要后端。尝试它的浏览器库产出低保真输出。IXPDF 不提供这些转换。
• AI 摘要 / 问答。需要模型和后端。在 2026 年无法在客户端以可接受质量完成。IXPDF 不提供 AI 功能。
• 非常大的文件。浏览器标签页有内存预算（通常几 GB）。2 GB 的 PDF 会在大多数浏览器中 OOM。服务器端工具用流式处理；浏览器工具无法以同样方式流式处理 PDF。

诚实的做法是在 UI 中把这些标记为 Planned、Research Required 或 Future Backend Candidate，而不是发布一个返回空输出并假装成功的假工具。这是本地优先工具与内容农场"工具"页之间的界线。

客户端处理之所以是有意义的隐私属性——而非只是营销声明——是因为不上传保证由代码的结构强制，而非由策略。没有可上传的服务器。页面没有携带文件内容的 fetch 调用。用户可以打开 DevTools，进入 Network 标签，运行一个操作，并验证没有请求携带文件。该保证是可审计的。

这不同于一个承诺24 小时后删除你文件的服务器端工具。那个承诺由你看不见的策略和基础设施强制。客户端处理由服务器的缺席强制。对敏感文件，这是重要的区别。

更多内容见 IXPDF 隐私页面和 关于 IXPDF。