把 PDF 转图片挪到浏览器之后，我抓包核对了一遍

我这人有个毛病，凡是说"本地处理不上传"的工具，我都要自己抓一遍包才信。这次抓的是 PDF 转图片，从选文件到四张图出来一共 13 个请求，没有一个是 POST，没有一个带请求体，三个是它自己的 JS 文件下行，剩下十个全是 blob: 开头——那是浏览器内存里的对象，压根没走网络。抓完我把这条链路从服务器上挪走了，账单那一栏的变化比我预想的小，真正省下来的是另一样东西。

先说怎么数的。开一个干净的标签页，F12 打开 Network 面板，勾上保留日志，从导入文件那一刻开始记，一直记到四张图出现，样例是自己造的四页图文 PDF，490 KB。结果 13 条：三条是 /pdf/to-html-preview-worker.js、/pdf/core.js、/pdf/to-html.js，剩下十条全是 blob: 开头的 document 和 image。非 GET 请求 0 条，带请求体的请求 0 条。前三条是它按需拉的解析和渲染代码，这个是必然的，总得有东西下来干活；后面所有 blob: 的都不是网络请求，是浏览器给内存里的 Blob 对象发的引用，面板会列出来但它不出网卡。这个验证方法不挑工具，任何号称本地处理的东西都能这么验，看有没有 POST、有没有带 body 的请求，比看隐私政策快多了。

然后是账。我原来的做法是服务端渲染，一份 490 KB 的 PDF 进来转出 494 KB 的图，一来一回接近 1 MB。入向流量通常不计费但要占连接和临时磁盘，出向流量要钱，各家云 0.5 到 0.8 元一 GB 不等。按一天 500 份算一个月 15000 份，出向流量差不多 7.4 GB，钱不多，也就几块钱。我挪这个功能之前，脑子里的理由一直是"省带宽"，算完这一步发现这个理由根本不成立——几块钱的事我犯不着折腾一下午。

真正贵的是 CPU。四页 216 DPI 我这边量到 3.0 秒，300 DPI 是 6.1 秒，这几秒是实打实占着核的。15000 份乘 3 秒是 12.5 个 CPU 小时，看着也不多，但它不是均匀分布的，是集中在几个时段，你得按峰值备机器不是按总量。我那台机器平时闲着，一到中午和晚上八九点就顶格，为这个我加过一次配置，加完之后大部分时间都在浪费。挪到浏览器之后这两项都归零，代价是首次加载要多下几个 JS。对我这种一个人做产品、峰值和低谷差十倍的场景，这个交换划算得没什么好犹豫的。

多页导出的产物是打包成 ZIP 给的，文件名保留原页码，样例报告-4页-page-001.webp 一直到 page-004。页码在文件名里而且补了零，这件事对脚本处理来说省事不少，不用靠 ZIP 里的顺序猜页序，直接正则拿出来排。我以前用过一个工具导出来是 image1.png 到 image10.png，字符串排序之后 10 排在 2 前面，那次半夜排了一个多小时的错才发现是这个原因，当时还怀疑过是我自己的排序函数写错了，把那段代码翻来覆去看了好几遍。现在看到补零的命名就踏实。单页导出还有个我没料到的细节，单独导第 2 页得到 124 KB，而全量导出那次里的第 2 页也是 124 KB，一个字节不差，说明单页不是另跑一套逻辑就是全量里挑一页，补图的时候不用重跑整份。

有两件事我得说清楚免得看着像通稿。一是这条链路本地跑完不代表这个产品所有功能都本地跑完，有些格式浏览器写不了，那些是要上服务器的，我只测了 PDF 转图片这一条。二是浏览器做这件事有上限，我拿一份 800×9000pt 的超长单页去试，选 216 DPI 和选 300 DPI 出来的图完全一样，都是 1456×16380，说明这类页面撞到了尺寸天花板，参数调了不生效，服务端没这个限制。所以要处理特别大的文件端侧不是万能的，这点得认。

工具是 https://imging.cn/pdf-to-image/ ，抓包那步花不了两分钟，别信我的，自己数一遍。