两周前我觉得在线 PDF 工具都要上传文件到服务器，太不安全了于是想做一个纯浏览器端处理的工具站。

现在站点上线了+ 个功能。Google 刚开始收录，日活不多但每天在涨。回头看，这两周踩的坑比我过去半年都多。

下面这 8 个坑，每个都是真刀真枪在生产环境遇到的。怎么说呢，如果你也在做浏览器端文件处理工具，希望能帮你少走点弯路。

从坑1来看，pdf-lib 加载大文件直接崩

使用者痛点： 使用者上传大文件时页面崩溃。导致不能正常使用工具

症状： 使用者上传一个 80MB 的扫描件 PDF，页面白屏，控制台报 RangeError: Array buffer allocation failed。

原因： pdf-lib 会把整个 PDF 读进内存，用 ArrayBuffer 存。浏览器对单个 ArrayBuffer 有大小限制，而且加载过程中内存会翻倍。

我的解法：

不是不用 pdf-lib，而是别让大文件一次性进内存。

对于超大文件，我做了两层保护：

1. 前端文件大小限制: 超过 100MB 的文件直接提示"建议用桌面软件处理"
2. 分片加载: 对于 Image to PDF 这种场景。图片是逐个嵌入的，每处理完一张就 imageBytes = null;

// 错误做法：20MB 的 ArrayBuffer 一直占着内存
const imageBytes = await file.arrayBuffer;// 20MB
const image = await pdfDoc.embedJpg;// 又拷贝一份
// imageBytes 还在内存里吃灰
// 正确做法：嵌入后立即释放
let imageBytes = await file.arrayBuffer;
const image = await pdfDoc.embedJpg;imageBytes = null;// 允许 GC 回收
但这只是缓解。说到真正的教训是，浏览器不是服务端。不要承诺处理无限大的文件!. 在 UI 上给使用者明确的文件大小预期,比后面调整代码更有价值.

坑2这方面，Web Worker通信开销被我忽略了

使用者痛点:: 大PDF转换速度极慢,导致体验差

症状:: 把PDF处理逻辑丢进Web Worker后,5页的PDF转换时间从3秒变成了15秒.

原因:: Web Worker和主线程之间传数据需要序列化/反序列化.PDF的Uint8Array在postMessage时会被拷贝.一个50MB的PDF。光是拷贝就要几百毫秒.

我的解法:

• 使用Transferable Objects把所有权转移给Worker而不是拷贝:

="" const="" main.js="" p="" pdfbytes="" pdfdoc="await" pdfdoc.save;="" pdfdocument.load;="" result="await" self.onmessage="async" self.postmessage;="" worker="new" worker.postmessage;="" worker，="" {="" }="e.data;" 注意:转移后main线程不能再访问pdfbyte<="" 转移所有权回去};="" 这里直接拿到所有权,没有拷贝="">

另一个教训的观点是。不是每个功能都需要Worker.对于5MB以下的文档主线程更快.最终方案是小于1OMB走主线程,大于1OMB走Worker!其实，.



症状:-批量压缩十几个PDF,进度条显示%但实际还没完成导致使用者误以为卡死并疯狂刷新.

原因:-仅统计已处理完毕数而忽略最终ZIP合并耗时阶段.

方法:

//正确分阶段显示进度:
阶段 :读取
阶段 :逐个压缩
阶段 :生成ZIP
阶段 :下载准备`


关键代码调整的观点是。function updateProgress{
requestAnimationFrame=>{
progressBar.style.width='${percent}%';})，}

//批量任务间添加休眠:
await new Promise);

`