构建通过了，发布说明写完了，下午4点57分，客户门户把文档PDF退了回来。那只是一份手册，却突然成了发布流程里最后一个没解决的依赖。

问题出在"压缩PDF"这个说法本身。它听起来像一次操作，实际上不是。PDF是一个容器，不是一种图片格式。同一个文件里可以同时装着文本流、嵌入字体、矢量图形、JPEG图像、无损图像、注释、表单、附件、元数据和好几代增量修改。

所以，两个页数相同的PDF，体积构成可能完全不同。一份100页的API参考手册，可能绝大部分是文字和矢量线条；一份10页的巡检报告，可能塞了十张全分辨率照片。用同一条流水线处理这两者很方便，但方便不等于正确。

第一个工程决策应该是分类。你不需要对文档做完美的语义建模，只需要足够的证据来选一个安全的首选策略。

三个信号，足够做一次预检

最实用的信号是：可提取文本、嵌入字体、以及页面尺寸级别的图像。用Poppler的几个命令就能拿到，不必自己写PDF解析器：

• pdfinfo：看页数、页面尺寸、文件大小、PDF版本
• pdffonts：列出嵌入字体
• pdftotext：抽取文本内容
• pdfimages -list：列出图像对象

如果pdftotext返回了可观的内容、pdffonts也列出了字体，这份文档大概率有可用的文本层。如果文本输出几乎是空的、而每一页都有一张大图，那它大概率是扫描件为主。两者都有，可能是混合文档，也可能是带OCR层的扫描件。

这套判断是概率性的。有些PDF把文字转成了矢量轮廓；有些带着质量糟糕、足以误导判断的隐藏OCR层。预检应该给出一个路由提示，而不是法庭判决。

还有一个容易踩的坑：不要只看第一页。混合文档在真实工作流里很常见——第一页是生成的封面，接下来五十页是扫描件，附录里又是可搜索的表格。只看第一页会制造虚假的确定性。写个小脚本抽样若干代表性页面，把证据留在构建产物里，比凭感觉靠谱。

选策略，先想清楚要保住什么

对文本为主的PDF，最安全的第一遍通常是结构性清理：对象流压缩、移除不可达对象、字体子集化、合并重复资源。它的压缩幅度比整体栅格化小，但可搜索性、可选文本、矢量图形和无障碍信息更有可能活下来。

qpdf这类工具适合做规范化和流压缩，但它没法凭空缩小已经以压缩JPEG字节存储的图像数据。这个边界值得记住：一条命令可以把PDF重写得很干净，体积却只降一点点。

图像为主的文档，最大的收益通常来自对图像降采样和重新编码。这会引出一串通用"压缩"按钮回答不了的问题：目标用途是什么？仅供屏幕阅读的审阅副本，不需要和印刷母版一样的有效分辨率。颜色是否承载信息？一张拍摄的收据也许能接受灰度，一张热力图不行。图像是自然照片还是界面截图？JPEG对前者效果好，对后者会在边缘制造难看的晕圈。

正确的质量参数是上下文相关的，应该由文档的用途决定，而不是从某段随机代码里抄来。

把每一页都渲染成位图再重建PDF，这个做法很诱人，因为它把复杂的对象图变成了可预测的图像序列。代价是可能丢掉可搜索文本、链接、表单字段、矢量锐度、标签和语义结构。对纯扫描件的分享副本，这笔交易可以接受；对带代码示例、可搜索标题和内部链接的技术手册，同样的做法可能解决了体积问题，却毁掉了文档最有用的特性。

所以评估一个压缩服务，不能只看最终的字节数。文件是小了，但它对读者来说还是同一种工具吗？

把校验写进流水线

命令成功退出，不等于文档成功产出。PDF处理器常被当成编译器对待：命令返回成功，输出就被接受。这不够。一个合法的PDF仍然可能缺页、小字不可读、链接断裂、OCR层重复，或者输出比输入还大。

最小校验应该比对页数、页面尺寸、文件大小和可提取文本，再把少量页面渲染成图片做目视检查。大文档抽样时，选一页普通正文、一页图像密集页、一页带表格或小标签的页面。随机抽样有用，按风险抽样更好。

还有一条规则：拒绝比输入更差的输出。压缩偶尔会让文件变大——很小的文本PDF在页面被渲染成图像后会膨胀，已经优化过的文档重写后可能多出开销。生产流水线应该比较前后体积，没有实质改善就拒绝发布候选文件。这条规则听起来理所当然，却经常缺失，因为团队只盯着"转换是否完成"。"没有改善"是一个有效结果，返回原文件好过自信地交付一个更大的文件。

最稳妥的工作流，是不要求一个文件满足所有用途：保留原始文件或高质量母版用于编辑、归档和打印，另外产出一份交付副本用于邮件、上传门户、移动阅读或聊天。这个分离改变了讨论的性质——你不再是在决定要不要永久劣化唯一的副本，而是在为已知目的地生成优化输出，同时保住事实来源。

至于什么时候值得自动化：一次上传被拦，不需要搭一个平台。如果问题只是单个PDF、截止时间就在眼前，搭本地处理栈很可能是错误的优化方向。浏览器端的工具可以处理交付副本，工程环境不用动。但习惯不变：留原件，在真正接收它的设备或门户上检查结果。

重复才是自动化的信号。当同一个来源反复产生同一种失败——比如报表系统每天早上导出图像密集的PDF——就把预检、转换、校验和兜底都写进任务里，记录输入体积、输出体积、页数、所选策略和校验结果。这些测量把"PDF压缩"从一个神秘按钮变成可观测的流水线，也让回归问题变得可见：如果模板改动导致报表体积翻倍，团队能在用户撞上上传错误之前看到这个变化。

没有通用的压缩预设，因为没有通用的PDF。有用的系统做的是：在满足目的地约束的前提下做破坏最小的改动，验证结果，并保留源文件。下午4点57分失败的那份发布手册，需要的不是什么英雄算法，而是一份更小的交付副本，以及一套能让下周不再重演同样意外的流程。