一份要等四十秒才打得开、滚动起来一顿一顿、在手机上还会自己闪退的 PDF，正在做一件很容易被误认成文件损坏的事。它并没有坏。它索要的内存超出了阅读器所能给的，而输的那一方是阅读器。
麻烦的是，单看文件大小几乎说明不了什么。40 MB 的文档可能秒开，8 MB 的却在爬——因为这两个文件之所以大，原因完全不同，而正是这些原因决定了哪种办法管用、哪种办法只会白白搭上画质。
「太大」到底指什么
「太大」并不是单一的门槛，而是四道不同的天花板；你撞上哪一道，决定了你会看到什么现象：
| 限制 | 大致在哪里开始卡住 | 症状 |
|---|---|---|
| 邮件附件上限 | Gmail 25 MB，Outlook 20 MB，企业服务器往往更低 | 邮件根本发不出去 |
| 网页上传限制 | 多数门户和政务表单为 10–50 MB | 还没开始上传就被拒 |
| 移动端阅读器内存 | 不一而足；图像密集的文件远不到 100 MB 就吃力 | 打开后闪退，或者压根打不开 |
| 桌面阅读器性能 | 没有硬性上限——只会逐渐变差 | 滚动迟滞、打开耗时、光标一直转 |
前两道是硬限制，会直接把文件挡回来。后两道是软的，而且取决于页面里装了什么的程度，远大于取决于总共多少兆字节。一千页的纯文本文档是轻松活；五十页满版照片的图册就不是。
大 PDF 为何会把阅读器压垮
PDF 的一页是一组绘图指令，渲染它就意味着执行这些指令。当某一页引用了一张 2500 万像素的照片，阅读器必须先把这张图完整解压到内存里，才能把它缩小到你的屏幕尺寸——一张 4 MB 的压缩图像，解压后可能占用 100 MB。连续滚动十来页这样的内容，只有几百兆内存可用的移动端阅读器就会耗尽内存，被操作系统直接结束掉。
另有两种情形以不同路径导向同样的结果。矢量图形——地图、CAD 导出件、复杂图表——单页就可能包含数十万条独立路径，而这一页每次出现时它们都得重新绘制一遍；这类文件在磁盘上往往很小，渲染起来却慢得离谱。而那些靠反复合并其他文档拼装起来的文件，可能积累了同一套嵌入字体的几十份副本，把体积撑大，却没多出任何一样看得见的东西。
究竟是什么占了体积
实际情况中，体积几乎总是压在下面这五处之一：
- 以不必要的分辨率扫描的页面。遥遥领先的头号成因。扫描仪默认就是全彩 600 dpi，产生的数据量大约是 150–200 dpi 的十倍，而后者用来阅读和打印文字已经绰绰有余。
- 按相机原分辨率嵌入的照片。随手放进报告里的手机照片有 1200 万像素，页面上大概只显示得出一百万。其余 90% 的像素被存储、被传输、被解压，却毫无用处。
- 未经压缩保存的扫描件。有些扫描仪和某些「打印成 PDF」的路径，会把页面图像按原始位图存放。这类文件极其庞大——每页几十兆字节——而且压缩效果惊人。
- 重复嵌入的字体。每合并一次，就可能再添一份相同的字体集。看不见，偶尔却占到文件的三分之一。
- 密集的矢量图形。地图、平面图和 CAD 导出件。在磁盘上体积不大，渲染起来却折磨人，而且这是唯一一种图像压缩完全帮不上忙的成因。
判断体积压在哪里
两个快速计算就能告诉你该用哪种办法，也免得你白白糟蹋一个本来就不可能变小的文件：
- 用文件大小除以页数。超过每页约 1 MB，说明图像占主导，压缩会立竿见影。若一个仍然很慢的文件每页远低于 500 KB，那问题出在矢量复杂度或页数上，压缩几乎撼动不了它。
- 试着在页面上选中文字。如果选不中，这一页就是图像——是扫描件——图像压缩正是对症的工具。如果文字能干净地选中而文件依然巨大，那体积就压在字体或矢量内容上了。
第二项检查还有个有用的推论。扫描件根本没有文本层，所以既搜不了，内容也复制不出来。既然你反正要处理这个文件，那把它送进 OCR PDF 就能在页面图像下方加上一层可搜索的文字，而外观分毫不变——一份笨重的扫描件由此变成真正能拿来用的东西。
三步让大 PDF 重新能用
对于占了大多数情况的图像密集型文件，在浏览器里不到一分钟就能搞定：
上传文件
打开 pdfdocshift.com/compress-pdf，把文档拖到上传区域。最大支持 200 MB 的文件，基本涵盖了所有阅读器吃力的情形。
按用途挑一个画质等级
高画质降采样比较保守，适合任何要拿去印刷的东西。中等以 150 dpi 左右为目标，是屏幕阅读和邮件发送类文档的正确默认值。低画质则用于「挤进硬性限制」比保真更重要的场合。
在完整缩放下检查结果
下载文件，找最精细的那一页——有小字、签名或印章的那页——按 100% 缩放而非适应窗口来看。如果文字锐利，这次压缩就是白赚的。如果显得发虚，就把画质调高一级重跑一遍。
什么时候压缩是错误的答案
压缩针对的是图像。如果体积不在图像上，它会让你搭上画质却换不回什么，这时你需要换一种思路。
- 特别长的文档。两千页的文件慢在页数，而不在字节。拆分 PDF 能把它切成章节或固定大小的段落，每一段都能秒开——而且对邮件限制来说，拆分通常也是更好的答案，毕竟收件人宁愿收到三个能看的文件，也不愿收到一个被退回的。
- 密集的矢量图形。图像压缩根本无从下手。请出图的人导出一版扁平化或降低细节的文件；在你这一端并没有真正有效的办法。
- 只需要其中几页时。把相关页面提取出来胜过压缩整份文档。从三百页报告里摘出的五页，比任何压缩所能达到的都小，读起来也更实用。
- 文件同时还损坏了。如果它既庞大又不可靠——有时打得开，有时卡住——那就先用 修复 PDF 修好它。压缩一个结构已损的文件，往往会把损坏固化进去。
从一开始就让 PDF 保持小巧
多数超大 PDF 是在生成的那一刻就被弄大的，起因是一个谁也没有刻意选过的默认设置：
- 文字用灰度、200–300 dpi 扫描。把黑白纸张按彩色扫描，会白白让数据量翻三倍。仅此一项改动，通常就比事后任何一轮压缩更有价值。
- 放进文档之前先把图片改小。缩到实际显示尺寸的照片，只占全分辨率原图的一小部分，看上去却毫无差别。
- 能导出就别用打印成 PDF。Word、Pages 和 Google 文档通过「导出」或「存储为 PDF」生成的文件，都比走打印对话框高效得多。
- 只合并一次，在最后合并。反复合并再合并，每过一轮就积累一批重复的字体数据。把最终文档在一次操作中拼装完成。
- 归档前压缩，而不是分发后。一旦一个庞大的文件发给了二十个人，体积问题就已经变成所有人的问题了。
最后还有一个值得记牢的区别：文件慢是体积问题，而文件压根打不开则不是。如果你的阅读器是直接报错而不是勉力支撑，那就先去看那条错误信息到底在说什么——压缩一个打不开的文件，是不会有用的。
常见问题
移动端阅读器可用的内存少得多，而 PDF 页面必须完整解压后才能显示——一张 4 MB 的压缩照片在内存里可能占用 100 MB。桌面电脑轻松就能吞下，手机则会耗尽内存，被操作系统关掉应用。文件并没有损坏，把它压缩以减少图像数据即可解决。
这取决于你撞上的是哪道限制，而不是某个单一数字。邮件上限是硬的：Gmail 25 MB，Outlook 20 MB，企业服务器往往更低。网页上传表单通常止步于 10–50 MB。阅读器性能没有固定天花板，只会逐渐变差，而决定它的更多是页面里装了什么，而非总体积——一千页文字比五十页照片轻松得多。
只要文档有真正的文本层，文字就不会。文字是以字符加字体指令的形式存储的，在任何尺寸下都会被重新锐利地绘制，压缩碰不到它。压缩降低的是图像分辨率——如果你的页面是扫描件，这一点就要紧了，因为那时文字本身就是图像的一部分。对扫描文档请选用更高的画质等级，并按 100% 缩放检查一页精细内容。
这是密集矢量图形的典型特征——地图、平面图、CAD 导出件和复杂图表，单页就可能包含数十万条独立路径，而页面每次出现时它们都必须重绘。这类文件在磁盘上很小、渲染却很慢，图像压缩根本无从下手。唯一真正的解法，是请出图的软件重新导出一版简化文件。
取决于体积压在哪里。用文件大小除以页数：高于每页约 1 MB，图像占主导，压缩会立竿见影。若一个仍然很慢的文件低于每页约 500 KB，那问题在页数或矢量复杂度上，此时拆成更小的文档能奏效，而压缩不能。至于邮件，拆分往往无论如何都更好——三个送达的文件胜过一个被退回的。
不会。压缩作用于嵌入的图像，文本层保持原样，因此可搜索的文档依然可搜索。扫描件本来就没有文本层，无论压不压缩都搜不了——若想搜索它，请把它送去 OCR，那会在页面图像下方加一层文字，而外观不变。