浏览器能处理多大的 PDF——以及怎么量出你自己那条线

「这个能处理多大的 PDF？」是个合理的问题，却只有不讲道理的答案：取决于文件、取决于操作、取决于你的机器；任何印在网页上的具体数字，对大多数读者都会是错的。能诚实给出的，是那个模型——会耗尽的三种资源，以及它们耗尽的顺序——再外加一次你在自己硬件上五分钟就能做完的测量。这篇就做这件事，并且刻意不提供基准表，因为我们没有测过你的电脑。

真正会耗尽的三样东西

1. 文件本身占的内存。本机工具要先拿住源字节，再构建新文档，再产出你要下载的成品。峰值常常是文件体积的几倍——页复制类操作请按「源文件的约两倍，加上产物体积」估算。
2. 渲染单页占的内存。栅格化一页需要一块「宽 × 高 × 4 字节」的画布。A4 在 150 DPI 约 8.7 MB，300 DPI 约 34.8 MB——每一页，在它被绘制的那段时间里。
3. 标签页自己的天花板。浏览器对每标签的 JS 堆和 canvas 可分配量都设了限；64 位桌面上这个上限通常是几 GB，手机上低得多。撞上去的时候，标签页不会报错——它会直接消失。

顺序很重要。一份 4 MB、200 页的文字型 PDF 几乎不占内存，每页渲染都是毫秒级。一份 180 MB、12 页的扫描件，在什么都没画之前就先花掉 180 MB，然后每页再叠上 300 DPI 的 35 MB。这就是为什么「多少页」是错误的问题，而「多少 MB、里面装的是什么」才是对的问题。

五分钟量出你自己那条线

1. 01先记下机器还剩多少可用内存

   Windows 看任务管理器的「性能」页，macOS 看活动监视器的「内存」页。开始之前把可用量记下来——浏览器真正能用的是这个数，不是总内存。

2. 02打开浏览器自带的任务管理器

   Chrome 和 Edge：Shift + Esc。Firefox：about:processes 页面。Safari：活动监视器里的进程列表。找到你马上要用的那个标签页，先记下它现在的内存，差值才有基准。

3. 03跑一次操作，盯住峰值

   开始转换，让任务管理器一直开着，记下它回落之前的最高值。那个峰值就是你的答案，而且只针对这份文件、这台机器。再拿一份两倍大的文件重复一次，看增长是不是线性的——页复制类操作通常是。

4. 04确认没有东西离开你的机器

   打开开发者工具的 Network 面板，再跑一次转换。不应该出现携带这个文件的请求：没有带着几 MB 请求体的 POST，没有上传进度。如果出现了，那这个工具就不是本机的，不管页面怎么写。

失败到底长什么样

• 标签页变成「噢，崩溃了」或「此页面出现问题」。渲染进程因超内存被杀了，什么都没保存下来。
• 进度卡在 99%，标签页不再响应。有时会恢复，有时系统开始换页，整台机器跟着变慢。
• 报出「无法读取文件」这类错误，或者 canvas 返回一片空白。移动端浏览器每标签的上限很紧，桌面版还早的时候它就已经到了。
• 产物莫名地小，却能正常打开——只是少了几页。这是最糟的失败，因为它看起来像成功。永远要数页数。

三个算例

这张表给出两条不同的曲线。复制页面的操作——合并、拆分、删除、提取、旋转——内存跟着文件体积走，所以一份大 PDF 不管页数多少都很贵。画像素的操作——压缩、PDF 转图片，以及编辑器里的预览——内存跟着「分辨率 × 页面面积」走，所以同一份文档在 DPI 翻倍时会贵四倍。先知道自己站在哪条曲线上，才知道在标签页倒下之前该拉哪根杆。

当文件大于你的机器

1. 把活儿拆开。先从原件里提取需要的页，或者分几段处理之后再合并——第二遍永远比第一次崩溃便宜。
2. 降分辨率。150 DPI 时一页占 8.7 MB，而不是 34.8 MB；对一份 300 页的扫描件，这是做完与做不完的差别。
3. 关掉用不上的东西。开着三十个标签页的浏览器已经在用你这次转换需要的内存，而先死的往往是干活的那个标签。
4. 换一台内存更大的机器。这是老实的答案：限制在本地，解法也在本地。

所以：没有基准表，没有编出来的「最大支持 250 MB」。三种资源、一个估算，以及一次五分钟就能给你自己机器真实数字的测量——而那才是唯一本来会适用于你的数字。