PDF 文件为什么这么大？从上传失败到压缩验证的完整排查

代码没有报错，PDF 也能打开，交付却卡在了“文件大小超过限制”。

先分清：到底是谁拒绝了这个 PDF

浏览器里的报错不一定来自应用

在 Web 项目中，用户上传一个较大的 PDF，页面可能只显示“上传失败”或者返回一个 413 状态码。表面上看，这是一个文件问题；实际上，请求可能还没有进入 Laravel，就已经被 Nginx 拦截。

Nginx 的 client_max_body_size 决定了请求体大小上限。若文件超过这个值，Web 服务器会直接拒绝请求，Laravel 的控制器、表单验证和异常处理都不会执行。此时继续修改 max 验证规则没有意义，因为应用根本没有拿到文件。

server {
    listen 443 ssl;
    server_name example.com;

    client_max_body_size 50M;

    location / {
        try_files $uri $uri/ /index.php?$query_string;
    }
}

修改配置后，需要先检查语法，再重新加载 Nginx。这里最好使用 reload，避免为了一个容量配置中断现有连接。

nginx -t
nginx -s reload

PHP 有两道容易混淆的限制

请求通过 Nginx 后，还要经过 PHP。upload_max_filesize 限制单个上传文件的大小，post_max_size 限制整个 POST 请求体。后者必须大于前者，因为表单请求除了文件内容，还可能包含字段、边界和其他附件。

upload_max_filesize = 50M
post_max_size = 55M
max_execution_time = 120
max_input_time = 120

一个常见误区是只修改 upload_max_filesize，却保留更小的 post_max_size。结果是配置看起来已经放宽，上传仍然失败。另一个误区是改错 php.ini。命令行、PHP-FPM 和不同 PHP 版本可能加载不同配置，因此应从实际运行环境确认当前值。

php --ini
php -r "echo ini_get('upload_max_filesize'), PHP_EOL;"
php -r "echo ini_get('post_max_size'), PHP_EOL;"

命令行输出只能证明 CLI 使用的配置。如果项目通过 PHP-FPM 运行，还应检查对应 FPM 池所加载的配置，并在修改后重新加载服务。

Laravel 的 max 使用 KB 计算

到达应用层后，Laravel 才会执行文件验证。文件规则中的 max 默认按 KB 计算，不是字节，也不是 MB。下面的规则允许上传 PDF，并把单文件上限设为 20 MB 左右。

use Illuminate\Http\Request;

public function upload(Request $request)
{
    $validated = $request->validate([
        'document' => [
            'required',
            'file',
            'mimes:pdf',
            'max:20480',
        ],
    ]);

    $path = $validated['document']->store('documents');

    return response()->json([
        'path' => $path,
    ]);
}

如果 Nginx 允许 50 MB、PHP 允许 50 MB，而 Laravel 只允许 20 MB，那么 25 MB 的文件应当得到可读的业务验证错误，而不是 413。三层限制可以不同，但必须有意设计。最外层负责保护服务器，应用层负责表达业务规则。

文件能上传，不代表它应该这么大

PDF 是容器，不是一张长图

解决上传限制之后，问题只解决了一半。把服务器上限从 20 MB 改成 200 MB，确实能让请求通过，却可能把一个不合理的文件继续送入存储、邮件、对象存储同步和第三方接口。容量会沿着整条链路放大成本。

PDF 内部可以同时保存文本、字体、矢量路径、位图、透明图层、表单和元数据。文本型报告的主体可能只有几百 KB，但嵌入的高清封面就占了十几 MB。扫描版 PDF 则可能把每一页都保存成一张高分辨率图片。还有一些导出工具会重复嵌入同一字体或图片资源，使文件在肉眼看不出变化的情况下持续增长。

因此，“PDF 有 40 MB”只描述了结果，没有告诉我们原因。压缩之前应先确定容量主要来自哪里，否则很容易用错误的方法换来很差的结果。

用命令快速查看文件结构

Poppler 提供的一组命令足以完成初步判断。pdfinfo 可以查看页数、页面尺寸和基本信息；pdffonts 可以确认字体是否嵌入；pdftotext 能判断是否存在可抽取的文本层；pdfimages 则可以列出内部图片的尺寸、颜色空间和编码方式。

pdfinfo document.pdf
pdffonts document.pdf
pdftotext document.pdf - | sed -n '1,20p'
pdfimages -list document.pdf | sed -n '1,30p'

如果一个 20 页文档包含 20 张接近整页尺寸的大图，它很可能是扫描文件。若文字可以正常抽取，同时只出现少量大图，容量可能集中在封面、照片或截图。若图片并不多，却嵌入了大量字体子集，就应回到生成工具检查字体和导出配置。

这些信号不能单独作为结论。例如，页面上看起来是文字，内部也可能只是矢量轮廓；扫描 PDF 也可能叠加不可见的 OCR 文本层。诊断的目的不是给文件贴一个绝对标签，而是判断压缩时最可能发生变化的对象。

为什么“重新打印为 PDF”有时有效，有时很危险

不少人遇到大文件时，会选择系统里的“打印为 PDF”。这种做法可能重新整理对象、移除部分无用数据，因此偶尔能显著减小体积。但打印过程也可能丢失书签、链接、表单字段、附件或可访问性结构，甚至把原本清晰的矢量内容重新栅格化。

如果 PDF 只是一次性的静态预览文件，重新打印也许够用；如果它包含目录跳转、表单、可搜索文本或需要长期归档，就不应把“能打开”当成完整验证。压缩和重建都可能改变文件行为，区别只在于改变是否可控。

压缩真正改变了什么

无损优化的空间通常有限

PDF 可以通过重新压缩内容流、清理未引用对象、合并重复资源和优化对象结构来减小体积。这类处理对页面外观影响较小，但如果生成器已经做过优化，继续无损处理得到的收益可能很有限。

例如，qpdf 可以重新生成对象流并压缩可压缩的流数据。它适合结构整理和初步优化，但不会凭空把一组高清扫描图变成小文件。

qpdf
  --object-streams=generate
  --compress-streams=y
  --recompress-flate
  input.pdf output-optimized.pdf

执行后应先比较输入和输出大小。如果只减少了几个百分点，这不一定是命令无效，而可能说明主要容量并不在可无损重压的对象中。

图片降采样才是常见的大头

扫描件、产品手册和图片型演示文稿通常依靠降低图片分辨率、调整 JPEG 质量或改变颜色信息来获得更明显的压缩。收益越大，视觉风险通常也越高。小字号、浅色线条、二维码、工程图和表格网格最容易先出现问题。

这里要区分“屏幕阅读”和“高质量打印”。一份只在手机上查看的材料，不需要保留面向大幅印刷的图片分辨率；但如果文档还要打印、放大或用于图像识别，同一套参数就可能不合适。

压缩强度不是技术上越高越好，而是输出文件必须同时满足容量预算和阅读需求。如果接收平台限制 20 MB，把 45 MB 压到 17 MB 就已经达成目标，没有必要继续追求 3 MB。

文字层和矢量内容不能被顺手牺牲

最激进的压缩方式之一，是把每页渲染成图片，再重新组装为 PDF。它确实能统一控制图片质量，却可能让文字无法搜索和复制，也可能让矢量图在放大后变模糊。

对于合同、技术手册、论文和报告，文字层本身就是文件功能的一部分。评估压缩结果时，不仅要看页面截图，还要验证搜索、复制、链接和书签。体积下降 80%，但读者无法搜索章节名称，这不能算成功优化。

建立一个可重复的处理流程

先定义容量预算和质量底线

压缩流程应该从目标开始。目标可能来自邮件附件上限、客户系统限制、移动网络体验或对象存储策略。最好预留一定余量，不要把输出精确卡在平台上限边缘，因为不同系统对 MB 的计算方式和请求开销可能不同。

质量底线则取决于内容。普通段落需要保持清晰和可搜索，表格中的小字与细线不能丢失，二维码必须能识别，页数和方向不能改变。如果文档含有表单、书签或内部链接，也应把这些功能写进验收条件。

有了这两个条件，团队讨论的就不再是“压得够不够小”，而是“这个交付副本是否满足目标”。

原始文件与交付文件分开保存

不要直接覆盖唯一原件。原始 PDF 应作为基线保留，压缩结果则是面向具体渠道的交付副本。命名可以使用 report-master.pdf 和 report-delivery.pdf，避免在多次尝试后出现无法追踪的 final-3-new.pdf。

对于偶发的大文件交付，如果没有必要在服务器上安装和维护额外组件，可以用 PDFCompress 生成交付副本。它提供高、中、低三种压缩模式，适合先从较保守的模式开始尝试，再根据容量结果逐步调整。单个文件最大支持 1 GB，同一轮可以处理最多 5 份 PDF，完成后直接下载且不会添加水印。这里的关键仍然是保留原件，并把下载结果交给同一套验证流程，而不是因为工具显示“完成”就立即发送。

用脚本设置交付前的大小门槛

如果 PDF 是 Laravel 定时任务或报表服务自动生成的，可以在分发前增加一个明确的大小检查。它不负责压缩，只负责阻止不符合交付条件的文件继续进入邮件或第三方接口。

<?php

function assertPdfWithinBudget(string $path, int $maxMegabytes): void
{
    if (! is_file($path)) {
        throw new RuntimeException("PDF 文件不存在：{$path}");
    }

    $size = filesize($path);
    $limit = $maxMegabytes * 1024 * 1024;

    if ($size === false) {
        throw new RuntimeException("无法读取 PDF 大小：{$path}");
    }

    if ($size > $limit) {
        $actual = round($size / 1024 / 1024, 2);

        throw new RuntimeException(
            "PDF 为 {$actual} MB，超过 {$maxMegabytes} MB 的交付上限"
        );
    }
}

assertPdfWithinBudget(
    storage_path('app/reports/report-delivery.pdf'),
    18
);

如果目标平台上限为 20 MB，内部门槛可以设为 18 MB，为编码差异和后续封装留出余量。异常信息应包含实际大小与目标值，这比笼统的“处理失败”更有助于排查。

压缩后如何验证

先检查结构是否完整

最基础的检查包括输出文件能否打开、页数是否一致、页面尺寸是否异常、文件大小是否真正下降。可以使用 pdfinfo 比较原文件与交付文件。

pdfinfo report-master.pdf   | grep -E 'Pages|Page size|File size'
pdfinfo report-delivery.pdf | grep -E 'Pages|Page size|File size'

如果页数变化，或者横向页面突然变成纵向，说明处理过程已经改变了内容结构。此时不应该继续上传，而应回到压缩设置重新处理。

再检查文字层与高风险页面

对需要搜索和复制的文档，可以比较压缩前后的文字抽取结果。字符数不必完全相等，但不应从大量文本突然变成接近零。

printf 'master: '
pdftotext report-master.pdf - | tr -d '[:space:]' | wc -m

printf 'delivery: '
pdftotext report-delivery.pdf - | tr -d '[:space:]' | wc -m

视觉检查应覆盖封面、普通正文、表格密集页、图片页和扫描附件。只看第一页很容易漏掉问题，因为混合型 PDF 的不同页面可能采用完全不同的内容结构。

可以把代表性页面渲染为 PNG，再对照原文件检查小字、细线、渐变、二维码和图表标签。

pdftoppm -f 3 -l 3 -r 144 -png report-master.pdf master-page
pdftoppm -f 3 -l 3 -r 144 -png report-delivery.pdf delivery-page

最后在真实入口完成一次测试

本地检查通过，不代表目标系统一定接受。第三方平台可能还有 MIME 类型、文件名字符、超时时间或预览转换方面的限制。最终交付前，应在真实入口完成一次上传，并确认接收端能够正常预览或重新下载。

这一步经常被忽略，因为团队把“生成成功”和“交付成功”当成了同一件事。实际上，生成器、Web 服务器、PHP、Laravel、存储和接收平台共同构成了文件链路。压缩只是其中一个环节。

总结

遇到 PDF 上传失败时，应先确认限制发生在 Nginx、PHP、Laravel 还是目标平台，而不是直接修改所有容量配置。文件能够上传之后，再通过字体、文字层和内部图片判断体积来源，选择适合的压缩方式。

可靠的 PDF 压缩流程需要保留原始文件，建立明确的容量预算，从较保守的模式开始生成交付副本，并在压缩后检查页数、文字层、代表性页面和真实上传结果。

真正值得优化的不是某一个数字，而是整条交付链路。文件变小只是结果之一；它仍然清晰、可搜索、能被目标系统接受，才是这次处理真正完成的标志。

本作品采用《CC 协议》，转载必须注明作者和本文链接