pdf.js压缩：前端处理PDF时该关注什么

先分清：压缩的是库还是 PDF 文件

很多人第一次接触 pdf.js 压缩，是把 pdf.js 的构建产物和 PDF 文件混在一起谈。pdf.js 的库文件经过打包工具处理后会变小，但这不会改变你加载的 PDF 本身的大小。反过来，用前端库去“压缩”一个 PDF，通常也不是 pdf.js 的职责——它擅长解析和渲染，不负责重写文件结构。

所以动手之前先问自己：页面加载慢，是因为 pdf.js 的脚本太大，还是因为 PDF 文件本身太大？如果是前者，可以看看JS压缩这类工具对构建产物的处理思路；如果是后者，则需要换一条路。

PDF 文件体积偏大时，前端能做什么

PDF 里塞满高分辨率图片、嵌入字体和冗余对象时，体积自然下不来。前端直接改写 PDF 结构并不轻松，但可以做一些外围工作：比如在上传前用 Canvas 把页面重新绘制成图片再导出，或者调用服务端接口完成真正的重编码。若想了解前端生成文件为何偏大，可以参考js压缩pdf：前端生成文件体积偏大的排查思路，里面从生成端分析了常见原因。

另一个常被忽略的点是：同一个 PDF 在 pdf.js 里渲染时，页面尺寸和缩放比例会影响内存占用，但不影响磁盘上的文件大小。别把渲染性能和文件压缩混为一谈。

pdf.js 自身加载优化的小思路

如果瓶颈在 pdf.js 的脚本体积，可以考虑按需加载 worker 文件、拆分渲染逻辑，或者只引入用到的模块。构建工具的分包策略往往比盲目压缩更有效。想进一步了解前端处理 PDF 的边界，js压缩pdf文件：前端能做哪些事这篇从能力范围角度做了梳理，适合在动手前建立预期。

还有一点：pdf.js 的 worker 文件如果和主包一起被打进同一个 bundle，首次加载会明显变重。把它单独输出、延迟加载，通常比反复压缩主包更立竿见影。

别踩这些坑

有人试图用 pdf.js 的 API 直接“另存为”一个更小的 PDF，结果发现导出文件反而变大——因为重新写入时可能丢失了原有的压缩对象流。也有人把 PDF 转成图片再嵌回页面，以为这样能减小体积，实际上图片格式选不好会让文件膨胀。

比较稳妥的做法是：先定位体积来源（图片、字体还是结构冗余），再决定是在生成端控制，还是在服务端做重编码。前端能做的更多是预处理和展示优化，而不是替代专业的 PDF 处理库。

相关文章

• pdf代码压缩技巧：从字体嵌入到对象流精简

  从字体子集化、图片重编码到对象流与交叉引用表精简，讲清PDF体积膨胀的常见成因与可落地的压缩思路。

• oracle时间戳转换格式化：别让类型和时区混在一起

  讲清 Oracle 时间类型、字符串互转、格式掩码与时区处理，附常用 SQL 写法和排错思路。

• linux时间戳转换格式化：命令行与脚本中的时区与格式处理

  介绍在 Linux 环境中将时间戳转换为可读日期并格式化的方法，涵盖 date 命令、时区处理、常见错误排查与脚本应用。

• js的代码格式化：从混乱脚本到可读代码的实操路线

  面向开发者的实操教程：讲清js的代码格式化该在什么时机做、怎么配置缩进与换行、如何处理压缩代码与语法错误，并给出排查思路。

• js格式化时间戳：从毫秒数到可读日期的转换思路

  围绕js格式化时间戳，讲解时间戳与Date对象的转换、时区处理、常见格式拼接及易错点，帮助开发者写出清晰可靠的时间显示逻辑。

常见问题