PDF 转图片的 DPI，我们最后是这样定档的

我们做过一次数据合规整改，被法务盯了三个月，从那以后凡是文件要出内网我都得先问一句能不能不出。PDF 转图片这条链路能在浏览器里跑完，是它能进我们工作流的前提，前提满足之后才轮到调参数。而参数这块我们踩了半年冤枉路——DPI 一直按最高档填，最近才把三档的实际代价量出来，顺带发现我们写在文档里的那条验收标准是空的。

样例是我自己造的，A4 四页，图文混排带一张表格，490 KB，输出 WebP 全部页面。144 DPI 四张 1192×1686 合计 317 KB 用 2.0 秒，216 DPI 四张 1788×2529 合计 494 KB 用 3.0 秒，300 DPI 四张 2483×3512 合计 647 KB 用 6.1 秒。体积涨得比像素慢很多，这点和我原来的预期不一样。我一开始是拿存储成本去说服组里降档的，数据出来发现这条根本立不住——四页文档从 300 降到 216 才省 153 KB，拿这个数去开会等着被人笑。真正的差别在时间，批量跑几百份的时候 3 秒和 6 秒是两回事，而且我们那个批处理是晚上跑的，慢一倍意味着第二天早上业务方拿不到数据。我最后是拿这条说服的。

格式也顺手测了。同样 216 DPI 四页合计：WebP 494 KB 用 3.0 秒，AVIF 552 KB 用 10.3 秒，PNG 1.28 MB 用 1.0 秒，JPG 1.36 MB 用 1.0 秒。AVIF 在这份样例上比 WebP 还大，而且慢三倍多，我们本来打算切 AVIF 的，看完这组数就搁置了。PNG 比 JPG 小这件事有点反直觉，我理解是页面上纯色块占比太高、有损编码在文字边缘反而费码率，但这是我猜的，没往下验。

真正让我改验收标准的是另一组数。那份样例是单页 800×9000pt 的超长页面，216 DPI 出来是 1456×16380、1.10 MB，300 DPI 出来还是 1456×16380、1.10 MB。两档产物一模一样。按 216 DPI 这页应该是 2400×27000，实际宽度只有 1456，反推有效 DPI 是 131，比最低那档 144 还低。我理解是编码那一步有个单边像素的硬上限，超长页面被整体等比缩到上限以内了，宽高比倒是一格没变，没有裁底。

对我们的影响很直接：验收标准里"导出图不低于 216 DPI"这句话是没法执行的，因为产物文件上不带你填的那个数，没有元数据可以断言。改成算的，有效DPI = 导出图宽度px ÷ (页面宽度pt ÷ 72)，这份样例就是 1456 ÷ 800 × 72 = 131。批量作业里把这行加进校验，低于阈值的挑出来人工看，比盯着设置值靠谱。写这个校验的时候我卡了一会儿，因为页面宽度得从 PDF 里读，而我们批处理链路上原本没有读 PDF 元信息这一步，为了一行校验多接一个解析库，组里有人觉得不值。最后是加了，理由是这类问题只会出现在长页面上，而长页面恰恰是没人会滚到底去肉眼检查的那种——真出问题也不会有人报上来。

定档我们最后写成四条：按下游定，只在页面上展示的走 144，归档和业务查阅走 216，要打印或者后面还要过 OCR 才上 300；超长页面单独走一条，先算有效 DPI，不达标的把那一页拆短而不是把 DPI 调大，调了也不生效；格式跟内容走，图文混排优先 WebP，下游明确要无损的用 PNG，AVIF 暂时不用；最后一条是每次换样例重跑一遍。第四条是被前三条逼出来的，我们最早就是拿一份样例的结论当通用规则用，用了半年才发现那份样例根本不代表我们真实的文件构成。

我用的是 https://imging.cn/pdf-to-image/ ，选它主要是这条链路在浏览器里跑完、文件不出内网，这在我们这儿是硬条件。参数怎么定还是得自己按文件量一遍，上面的数换一批文档大概率对不上。