一份 14 页报告导成 PDF，我顺手查清了它在哪儿处理

前几天整理一份 14 页的内部报告，需要导成 PDF 发出去。我用图映的「HTML 转 PDF」做的，原来 4.82MB，导完 1.56MB，生成时间也从 5.3 秒降到 2.6 秒，体积小了不少。得先说清楚，这就是我这一份文件的实测数，页面结构不一样结果差很多，不是什么通用值。

体积我不太意外，倒是顺手想弄明白一件事：这份还没对外的东西，转换时到底在哪儿处理的。查下来分得挺清楚。导入文件、读目录、把资源映射好、生成完整预览，这几步都在我自己浏览器里跑，翻来覆去看预览，没东西离开本地。

真正往外走的只有一步。点「转换」之后，它把当前页面打成一份去掉脚本的自包含快照，提交到服务端生成 PDF，生成完临时文件随请求就删了。所以我不能说它零上传——转换那下确实走了服务端；但也就那一帧快照出门，不是把我整个操作都传出去。

顺带说下这份快照到底是什么：不是把我的原始文件整包传上去，是把当前这一帧连同用到的资源内联成一个文件、再把脚本删掉，服务端拿到的是张「死」页面，照着画版面就行，跑不了任何交互。这也是它用完能直接删的原因——服务端根本没留下可运行的东西。

查到这儿我又多问了一句：那为什么单单转换要出门，前面都能在本地？后来想明白，卡点在排版。我原先想当然以为版面是工具自己排的，其实不是——输出 PDF 的排版和生成用的是浏览器级引擎（Chromium / Skia），工具管的是本地预览、存哪一帧、页面尺寸策略和生成后的无损优化，画版面这件重活它没自己造轮子。问题是这套引擎要在每个人电脑上排出一模一样的版面，太难了：本地浏览器版本、装没装某个字体、内核新旧，差一点版面就歪一点。丢到服务端一套固定环境里去跑，出来的 PDF 才稳定，代价就是得把那一帧快照传上去一趟。这么一想，我倒不觉得「有服务端」是偷工，而是为了版面一致不得不这么分。

顺带把同一个图映里三个功能的差别也记一下：「PDF 压缩」和「PDF 转 HTML」都是全本地的，只有「HTML 转 PDF」因为要调这个引擎生成版面，才有服务端这一环，别把三者记混了。要是我手上那份文件死活不能出本地，那我干脆不用这个转换功能，走别的本地路子。

那怎么判断哪些文件能走、哪些不能走？我给自己的标准很土：这份内容丢出去一次，会不会出事。像这回这种普通内部报告、最后本来也要发给合作方看的，走一次快照即删的服务端转换，我认了；可要是里面有客户的身份证号、没公开的报价、还没签字的条款，我就不会图这点省事，要么留在本地另想办法，要么先把敏感字段抹掉再转。

我的结论很朴素：真正涉密、带隐私的网页，我不会走这条有服务端的路；普通报告这种，一次快照即删，我能接受。想自己看清链路，去 imging.cn 上走一遍就明白了。