2026 文档转 PDF 服务器租用配置手册：Gotenberg 渲染并发与队列怎么调 + 上线避雷全攻略

2026 文档转 PDF 服务器租用配置手册：Gotenberg 渲染并发与队列怎么调 + 上线避雷全攻略

把 PDF 渲染当成一门「CPU 密集型服务」去配机器，几乎是所有自托管文档转换项目第一天就踩的坑。Gotenberg 是一个 Docker 化的 PDF 转换 API（镜像 gotenberg/gotenberg:8，MIT 许可），容器里打包好了 Chromium、LibreOffice 和一组 PDF 引擎（QPDF、pdfcpu、ExifTool），你只要往 3000 端口丢一个请求，回来就是一份 PDF。正因为封装得太干净，很多人会默认它是个「轻量 HTTP 服务」，于是拿一台 1 核 2G 的机器就上生产，结果第一个月末批量开票的晚上，内存打满、容器被 OOM 杀掉、请求一串 503，业务侧看到的是「导出按钮点了没反应」。

真实情况是：Gotenberg 的瓶颈在内存，不在 CPU。单个 Chromium 标签渲染一份 40 页 HTML 报告大约要吃 300–600MB，LibreOffice 转带图表的表格与之相仿，实测突发并发峰值约 310MB；而 CPU 反而常常闲着，2 核 VPS 通常就够用。这跟视频转码、数据库索引、大文件回程这类负载完全不是一个形状——它是典型的「突发短任务型渲染负载」：请求来得急、单次持续几秒、内存瞬时拉高然后释放。配机器的思路必须顺着这个形状走，而不是照搬「核数越多越好」的直觉。

这篇手册面向的是正在给下面几类场景选型的人：发票与对账单的批量生成、合同与凭证的归档、报表夜间批处理、以及自带 PDF 导出功能的 SaaS。我们会把并发上限、队列行为、超时、自动回收、内存档位、横向扩容、安全面和 LibreOffice 路线一条条拆开讲，并给出一张可直接抄的配置清单表。所有硬数字都来自已核验的官方口径与实测，凡是需要按你的实际文档去定的地方，会明确写成「需实测」「以实测为准」，不给你编一个好看但不存在的数。

发票、对账单、合同归档、夜间报表：谁在为一台 PDF 渲染服务器选型

先说清楚谁需要认真读完这篇。第一类是最常见的财务类批量生成：每月 1 号凌晨把上个月几万条账单渲染成 PDF，尺寸不大、模板固定，但峰值极其陡峭——平时 QPS 是 0，出账日那几个小时可能同时涌进几百个请求。这类负载怕的不是慢，怕的是「慢到一半崩了」，因为崩了之后重试会带来重复渲染，账单重号或者重复发送是真金白银的损失。

第二类是合同与凭证归档。它的特点是单份文档可能很大（几十页带签章的合同），而且往往要求输出 PDF/A-1b、PDF/A-2b 或 PDF/A-3b 这类归档格式，Gotenberg 本身支持。归档场景对吞吐不敏感，对「渲染结果是否稳定可复现」极其敏感——同一份 HTML 今天转和半年后转，产出的 PDF 最好字节级一致或者至少排版一致，这就牵扯到字体、Chromium 版本、模板依赖资源的管理，也牵扯到 --chromium-restart-after 这类回收参数会不会改变渲染环境。

第三类是报表夜间批处理，第四类是 SaaS 里的「导出 PDF」按钮。这两类的容忍度截然相反：夜间批处理可以排队，等三十分钟无所谓，只要不失败；而 SaaS 在线导出是用户按了按钮盯着转圈，超过几秒就觉得卡，你必须要么让它快，要么让它快速失败并给出明确提示。理解了这个差异，才能明白为什么 Gotenberg 把「超出并发直接 429」设计成一个可选行为，以及为什么我们建议在线导出场景一定要开队列上限。

单个 Chromium 实例最多 6 个并发：队列、429 与快速失败的取舍

Gotenberg 最硬的一条限制是：单个 Chromium 实例最多 6 个并发转换，由 --chromium-max-concurrency 控制，默认值就是 6。超过 6 的请求不会报错，而是进入队列等着。这里有个关键的默认行为容易被忽略：--chromium-max-queue-size 默认是 0，意思是队列不限制长度。也就是说，如果你不改任何参数，在月末批量开票这种尖峰下，第 7 个请求开始就排队，队列可以无限长——用户看到的不是「系统忙」，而是一个永远转不完的圈，直到上游（你的业务服务器、Nginx、浏览器）先超时断开。

一旦你给 --chromium-max-queue-size 设了上限，行为就变了：队列满的时候，新请求会被快速返回 429，不再占用任何渲染资源。实测数据很直观——把并发设为 1、队列设为 1，同时打 4 个耗时 2 秒的请求，结果是 1 个在渲染、3 个在 6 毫秒内被 429 拒掉。6 毫秒是什么概念？上游几乎立刻拿到「我现在忙」这个信号，可以立刻决定是稍后重试、切另一个实例、还是给用户弹一句「当前导出排队人数较多，请稍后再试」。

所以我们的立场很明确：宁可快速失败，也不要无限排队。排队看起来「不丢请求」，实际上是把压力转化成延迟，而延迟会一路传导到上游的连接池、线程数和用户耐心上，最后变成一次连片的超时雪崩。429 是可控的、可观测的、可重试的信号，你的调用方只要实现一个带退避的重试，就能把尖峰削平；而无限队列把尖峰整个吞进去，只是在一个你看不见的地方慢慢胀大，直到把容器内存吃穿。对在线导出场景，建议队列设一个小值（比如并发数的 1–2 倍）；对夜间批处理场景，可以留较大的队列，但必须配一个上游的总超时兜底。

40 页 HTML 报告 300–600MB：把单标签内存换算成容器内存上限

内存是这台机器唯一需要认真算的变量。已知的口径是：单个 Chromium 标签渲染一份 40 页 HTML 报告约 300–600MB，LibreOffice 转带图表的表格与之相仿，实测突发并发峰值约 310MB。注意这个「约」字——它跟你的模板复杂度、图片数量、字体嵌入方式强相关，所以下面所有换算都请你把自己的实测值代进去重算一遍，不要直接抄结论。

换算方法很简单：容器内存上限 ≈ 并发数 × 单标签内存上限 + 引擎自身常驻基线 + 抖动余量。其中引擎基线（Chromium 主进程、Gotenberg 自身、可能的 LibreOffice 常驻）具体多少以实测为准，不同版本差异不小，这部分不要猜。我们按「单标签取上限 600MB」这个保守假设往下推三档：

第一档 1GB：600MB 留给一个标签，剩下约 400MB 要覆盖引擎基线和抖动，实际只能放心地并行跑 1 个重标签，或者 2 个轻量标签。这一档对应官方与社区的实践建议——1GB 给个人/单用途场景。如果你只有偶尔从后台导一份报表，1GB 够，但请把 --chromium-max-concurrency 从默认的 6 往下压（比如压到 2），否则默认并发会让 6 个标签同时申请内存，1GB 容器必然 OOM。

第二档 2GB：600 × 2 = 1200MB 给标签，剩下约 800MB 给基线和抖动，可以稳定并行 2 个重标签，轻量文档可以到 3–4 个。这一档是「需要并行渲染」的入门配置，也是我们认为大多数中小批量场景的起点：并发保持默认 6 是可行的，但前提是你的单份文档远小于 40 页那种体量；如果文档普遍偏重，就把并发调到 3–4，宁可让请求进队列。

第三档 4GB：按同样的算术，标签侧能放 3–4 个 600MB 的重任务，剩下的空间足够容纳基线和较剧烈的抖动。但到了这一档，我们反而建议你停下来想一个问题：是把 4GB 给一个实例、把并发开到 6，还是拆成两个 2GB 实例各跑一半？答案几乎总是后者，原因在下一节讲。至于 CPU，2 核 VPS 通常就够用——渲染确实是 CPU 活儿，但它的峰值是短促的，CPU 的排队延迟远小于内存不足带来的 OOM 风险，把预算花在内存上更划算。

--api-timeout 与 --chromium-restart-after：两个默认值为什么几乎必改

第二个容易踩的坑是超时。--api-timeout 默认 30 秒，超时返回 503。这个实测也很清楚：把上限设成 5 秒，一个 waitDelay=8s 的请求正好在 5.0 秒返回 503，说明计时是准的、行为是可预期的。30 秒对「把一个 URL 渲染成 PDF」是合理的，但一旦你的文档是大部头，或者走的是 LibreOffice 路线（.docx/.xlsx/.pptx/.odt 那一挂），30 秒常常不够。实践建议是给大文档或 LibreOffice 转换提到 60 秒。要提醒的是，这个参数同时是你的「失控保护」：一个渲染卡死的请求如果不被超时砍掉，会一直占着一个并发槽位，6 个槽位被占满之后整个实例就废了。所以调大可以，但别调到「形同虚设」。

第三个坑是自动回收。--chromium-restart-after 默认每 100 次转换重启一次 Chromium，--libreoffice-restart-after 默认 10 次。很多人看到「重启」两个字就想关掉它，觉得会影响性能，于是设成 0。这是个坏主意：设为 0 会关闭回收，长跑的引擎会越长越肥——Chromium 运行久了会积累缓存、僵尸标签、内存碎片，LibreOffice 更是出了名的长时间运行后会膨胀。默认值的存在就是为了在「重启开销」和「内存泄漏累积」之间取一个平衡点。

我们的建议是保留回收，但要按你的负载重新定值。如果你的单份文档内存占用很大（接近 600MB 上限），100 次才重启可能太久，中间已经出现过 OOM 了，那就把阈值调小，比如 30–50 次；如果你的文档都很轻，100 次重启的开销其实可以忽略，保持默认即可。LibreOffice 那边的 10 次更保守，本身就反映了它更容易膨胀这个事实，一般不需要动，除非你明确观察到每次冷启动的耗时已经影响到批处理的整体时长——这时候再权衡，而且这个权衡必须用你自己的实测数据做，不要拍脑袋。

发票批量、归档、SaaS 导出三种负载下的配置清单对照

下面这张表把前面所有推导收敛成可直接抄的配置。需要说明的是：表中的容器内存上限是按「单标签取 600MB 上限」这个保守假设推出来的，如果你的实测值更接近 300MB，那么同样的内存可以跑更高的并发；「需确认事项」一列是下单前必须跟自己业务侧或供应商对齐的东西，不是可选项。

这张表里最容易被跳过的一列是最后一列。很多团队照着中间四列配完就上线，然后在第一个尖峰里发现：原来账单重试不幂等、原来前端把 429 当成 500 弹了个「系统错误」、原来模板里引用了外网字体导致归档文件半年后渲染不一致。这些都不是加内存能解决的问题，它们属于「上线前就该问清楚的」部分，我们在文末的验收清单里会再收一遍。

一次月末开票尖峰要几个实例：用并发 6 与队列纪律反推容量

有了并发上限和内存档位，就可以做一次完整的容量反推。这里用一个纯假设的场景走一遍流程，你把自己的数字代进去即可。假设某财务系统每月 1 号要出三万份对账单，全部挤在两个小时内；再假设单份渲染耗时接近实测示例里的 2 秒量级。那么单实例在并发 6 的情况下，理论吞吐大约是每秒三份，两小时的理论上限在两万份出头——已经低于三万了，也就是说一个实例肯定不够，而且这还是没算任何抖动、重试和回收重启开销的理想值。

按理想值打折来估工程容量（这个折扣系数是经验取值，请按你的实测修正），单实例按每小时七千到八千份算，两个小时约一万五千份，那么三万份需要两个实例才勉强够，三个实例才有余量。再叠加内存约束：突发并发峰值实测约 310MB 是单标签量级，而按 40 页报告的 300–600MB 区间取上限做保守设计，2GB 容器一般只敢稳定并行两个重标签——所以实例数最终往往不是由吞吐决定的，而是由「每实例能安全开多少并发」决定的。这就是为什么我们建议先定内存档位、再定每实例并发、最后用「总吞吐 ÷ 每实例吞吐」反推实例数，顺序反了会得出一个跑不起来的方案。

算完容量还要算一遍「失败侧」。三个实例、每实例并发 4、队列设 4，那么瞬时能接纳的是三乘以八、二十四个请求，超出的一律在毫秒级拿到 429。你的上游必须能接住这个 429：理想做法是客户端做指数退避重试，重试次数上限设三到五次，并且把重试均匀打散（加随机数抖动），否则所有被拒的请求会在同一时刻齐刷刷地再来一遍，形成新的尖峰。如果业务方不愿意改代码接 429，那就退而求其次——在 Gotenberg 前面放一个你自己的排队网关，由网关统一持有请求并限速下发，但这样又回到了「排队等待」的路子上，请务必给网关也设一个总超时，别让用户在月末那一晚干等一个小时。

横向加实例而不是堆并发：多实例负载均衡与 /health 探针的 1/N 容错

前面留了一个问题：4GB 单实例、并发开到 6，还是拆成两个 2GB 实例各跑一半？答案是后者，而且这个答案来自 Gotenberg 自身的设计前提——它在请求之间不保存状态。官方与社区的共识都是「横向加实例 + 负载均衡」，而不是把单实例的并发调大。原因有三层，每一层都比上一层更要命。

第一层是故障半径。Chromium 是个复杂的东西，它偶尔会崩，或者因为某个畸形页面卡死在一个槽位上。单实例 6 并发时，崩一次你就损失 100% 的渲染容量；拆成 N 个实例后，一个实例出问题只损失 1/N，剩下的实例还能继续接单，负载均衡把流量摘走即可。第二层是回收重启的抖动：--chromium-restart-after 触发的重启是单实例行为，实例越多，同一时刻正在重启的比例越小，整体吞吐曲线越平滑。第三层是弹性：批处理窗口来了就临时多拉两个容器，窗口过去再缩掉，这种按小时伸缩的能力是「把单机并发调大」永远给不了的。

落地上有两个小细节值得记牢。其一，Gotenberg 提供了 /health 端点，可以直接挂到负载均衡或容器编排的健康检查上，不需要你自己写一个探活接口；判定为不健康的实例自动摘除，比人工盯日志靠谱得多。其二，多实例之后，每个实例仍然要各自设好 --chromium-max-queue-size，别以为有了负载均衡就可以无限排队——负载均衡只会把请求公平地分发到各个实例的队列里，队列不设上限的话，每个实例都会各自攒出一长串，最后大家一起超时。横向扩容解决的是容量问题，队列纪律解决的是行为问题，两者不能互相替代。

无认证服务绝不能暴露 3000 端口：allow/deny list 挡住 SSRF 与任意文件读取

说完性能说安全，这一节是全文最不该跳过的部分。Gotenberg 自身没有任何认证机制，任何能访问 3000 端口的人，都能让它去抓取任意 URL 并烧你的 CPU。这不是理论风险，它是一个默认开放的、功能完整的「代理 + 渲染器」：别人可以拿你的机器去探测内网地址、去爬别人的站、去把某个大文件反复渲染把你的内存打满。所谓 SSRF（服务端请求伪造）在这里不是漏洞，而是这个服务的正常功能——/forms/chromium/convert/url 这个路由本来就是「你给我 URL，我去抓」。

所以第一条铁律：Gotenberg 必须放在内网或容器网络里，绝不能把 3000 端口直接开在公网上。业务服务器在同一个网络内调用它，对外只暴露你自己的应用。如果确实有跨网络调用的需求，那就在前面加一层你自己的鉴权网关，而不是指望 Gotenberg 帮你做认证。第二条是 URL 过滤：用 --chromium-allow-list / --chromium-deny-list 做白名单或黑名单。默认的 deny 规则里包含 ^file:(?!//\/tmp/) 这类模式，目的就是防止有人用 file:// 协议去读 /etc/passwd 这样的本地文件——这个默认规则请保留，别为了图方便把它清掉。

实际配置时，我们更推荐用 allow-list 而不是 deny-list。黑名单是「我知道哪些是坏的」，而攻击者的想象力永远比你的黑名单长；白名单是「我只允许这几类地址」，剩下的全部拒绝，这对渲染服务尤其合适，因为你要渲染的 URL 通常就是自己家的几个域名。如果你的模板里引用了外部字体、图片或 CDN 资源，注意白名单要一并覆盖这些域名，否则会出现「页面能渲染但样式全丢」的诡异问题——这类问题排查起来很费时间，建议在上线前就把模板的所有外部依赖列成清单，逐条对照白名单。

只读容器 + tmpfs + --api-body-limit：把渲染沙箱收紧到最小面

即便放在内网，也建议按「这个服务随时会收到恶意输入」的标准来加固。第一招是文件系统：容器以 read_only 方式运行，只把 /tmp 和 /home/gotenberg 挂成 tmpfs。渲染过程中确实需要写临时文件（下载的网页资源、中间产物、LibreOffice 的工作目录），tmpfs 提供了可写性，同时保证这些东西落在内存里、容器一重启就烟消云散，不会在宿主机磁盘上堆积垃圾，也不会被利用来做持久化落地。

第二招是限制上传体量，用 --api-body-limit。Gotenberg 的转换是「你上传文件 → 它输出文件」的模式，如果不限体量，一个几百兆的 .docx 就能把内存和磁盘 IO 同时拖垮，而且这种请求往往是并发打过来的。给它设一个明确的、略大于你业务最大合法文档的阈值，超出的直接拒绝，比让它进去跑一半再 OOM 要健康得多。这个值定多少没有通用答案，得看你实际业务里最大的文档是多大——这一步请用真实样本量一量，别估。

第三招是监控方向的调整：Gotenberg 的 Prometheus 模块已经弃用，新做的监控应该基于 OpenTelemetry。如果你现在手上有一套基于 Prometheus 抓取的旧看板，迁移时要留意这一点，别把时间花在一个已经被官方放弃的集成上。对渲染服务来说，最值得盯的几个指标其实很朴素：并发槽位占用率、队列长度、429 的数量、503（超时）的数量、容器内存水位、以及 --chromium-restart-after 触发的频率。这几个指标画在同一张图上，你一眼就能看出「是容量不够」还是「有请求在拖后腿」。

.docx 走 LibreOffice 为什么又慢又吃内存：什么时候必须拆到独立实例

Gotenberg 有两条渲染路线。一条是 Chromium 路线，走 /forms/chromium/convert/url 和 /forms/chromium/convert/html，负责 HTML、URL、Markdown 转 PDF，这是我们前面所有并发与内存讨论的主战场。另一条是 LibreOffice 路线，走 /forms/libreoffice/convert，负责 .docx、.xlsx、.pptx、.odt 这类办公文档。此外 /forms/pdfengines/merge 提供合并、拆分、加密、水印等后处理能力，PDF/A-1b/2b/3b 归档、Factur-X/ZUGFeRD 电子发票也是它的能力范围。

这两条线的资源画像差别很大，必须分开对待。LibreOffice 转换通常更慢、更占内存——转带图表的表格时，内存占用与 Chromium 渲染 40 页 HTML 报告相仿（约 300–600MB），但它还要额外承担办公文档的解析开销，尤其是带图表、带嵌入对象、带复杂样式的表格文件，耗时经常显著高于一次网页渲染。这也是为什么 --libreoffice-restart-after 的默认值是 10 次，比 Chromium 的 100 次激进得多：LibreOffice 长跑后的膨胀问题更明显，官方不得不用更频繁的回收来对冲。

所以我们的建议是：只要你的业务里同时有 HTML 渲染和 Office 文档转换，就把它们拆到不同的实例上，甚至不同的机器上。理由不是「性能会更好」这么简单，而是故障隔离——Office 转换的长任务会把并发槽位占满、把内存拉高，混跑的话，一个用户上传了一个 80MB 的 .xlsx，就能让你所有在线 HTML 导出一起变慢。拆开之后，两条线各自有独立的并发、队列、超时和回收策略，Office 那边可以设更小的并发（2–3）、更长的超时（60 秒）、保留默认 10 次回收；HTML 那边保持默认 6 并发与 30 秒超时。如果 Office 转换的耗时已经长到不适合同步等待，那就走 webhook 异步回调，让业务系统提交后去干别的事，转换完成再回调通知。

批量流水线选无状态 API，人工偶发处理选带 UI 的 Stirling-PDF

经常被拿来和 Gotenberg 一起提的还有 Stirling-PDF，另一个常见的自托管 PDF 工具。它的技术栈是 Java，自带交互界面，做的是合并、拆分、压缩、OCR 这一类操作，定位是「人打开浏览器手工处理文件」。它和 Gotenberg 的根本差别不是功能多少，而是「交互 UI vs 无状态 API」。这个差别决定了它们几乎没有正面竞争关系，选型时也不该纠缠于「哪个更强」。

我们的立场很直接：凡是批量流水线场景，选无状态 API（Gotenberg）；凡是人工偶发处理场景，选带 UI 的工具（Stirling-PDF）。判断标准只有一条——谁在发起这个操作。如果是你的后端代码在循环里调用几千次，那就要一个没有会话、没有界面、没有状态、可以随便横向加实例的东西，Gotenberg 正合适。如果是运营同事偶尔要手动把两份 PDF 拼一下、给一个扫描件做 OCR，那给他一个有按钮的页面远比教他调 API 效率高。至于 Stirling-PDF 的资源占用具体多少，本文不引用任何数字，请以官方文档与你自己的实测为准——它的负载形状（常驻 Java 服务 + 人工触发）跟本文讨论的突发短任务渲染本来就不是一回事，硬凑在一起比较没有意义。

还有一个常被忽略的折中方案值得提一句：Gotenberg 支持通过 S3 预签名 URL 直取直传，业务服务器完全不用中转文件。这意味着在大批量场景里，你可以让业务系统只负责生成签名和派发任务，文件由渲染节点直接从对象存储拉取、产物直接回传，业务服务器的带宽和磁盘完全不参与。对夜间批处理这种量大的场景，这个省下来的不只是带宽，还有一整条可能成为瓶颈的链路。

一万网络在渲染型 VPS 与内网互联两个推荐项上的摆位

回到配机器这件事。这类突发短任务型渲染负载，我们通常只推荐两个方向，其余的都可以往后放。第一个方向是「内存优先的渲染型 VPS」：2 核打底，内存按前面的三档推算来选——起步 2GB，文档偏重或者要并行渲染就往上加，预算花在内存上比花在核数上划算得多，因为 CPU 在这里本来就不是瓶颈。如果你的业务有明显的批处理窗口，还可以问一问按小时弹性扩容的可行性，让实例数跟着窗口走。

第二个方向是「内网互联与多节点摆位」。前面反复强调 Gotenberg 无认证、不能暴露公网，那么它就必然需要一个内网环境：业务服务器和渲染节点之间要走内网，多个渲染实例之间要能被负载均衡统一调度。这就要求供应商在同一机房内能给你多台机器组内网，并且内网带宽足够承载文件传输。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。

需要说清楚的是，我们不建议一上来就上物理机或者大规格独服。渲染负载的特点是「可以横向拆」，两台中等规格的机器组成的小集群，在容错上天然优于一超大规格的单机：一个实例崩了只损失 1/N 容量，一个实例重启时其他实例照常接单。把预算拆成两到三份、每份配好独立的内存上限和队列纪律，比把同样的钱堆在一台机器上更符合这个负载的形状。真到了需要更大规格的时候，也是建立在「我已经用集群跑顺了、知道单点瓶颈在哪」的基础上，而不是拍脑袋先买大的。

Gotenberg 文档渲染上线前的服务器验收清单

验收第一项：内存与并发是否匹配。用你最重的真实文档跑一遍，量出单标签的实际峰值内存，代回「并发 × 单标签 + 基线 + 余量」这个公式，确认容器内存上限留足了余量；确认 --chromium-max-concurrency 已经按内存档位调过，而不是无脑留着默认 6。验收第二项：队列纪律是否建立。--chromium-max-queue-size 是否已设上限，429 是否被上游正确识别并实现退避重试，重试是否幂等（尤其是账单类业务，重复渲染的代价要先想清楚）。

验收第三项：超时与回收。--api-timeout 是否按文档体量和路线调整（大文档与 LibreOffice 建议 60 秒）；--chromium-restart-after 与 --libreoffice-restart-after 是否保留了回收而没有被设成 0。验收第四项：安全面。3000 端口是否已经确认不暴露公网，只在内网或容器网络可达；--chromium-allow-list 或 --chromium-deny-list 是否配置，默认的 file:// 相关 deny 规则是否保留；--api-body-limit 是否设了合理阈值；容器是否 read_only 且 /tmp、/home/gotenberg 挂了 tmpfs。

验收第五项：可观测与扩容路径。负载均衡的健康检查是否指向 /health；监控是否已切到 OpenTelemetry 体系而非已弃用的 Prometheus 模块；并发占用率、队列长度、429 数、503 数、内存水位这几个指标是否都能看到。验收第六项：业务侧对齐。模板引用的外部字体与图片是否全部在内网可达或已列入白名单，PDF/A 归档等级是否确定，前端对排队与失败是否有明确的文案而不是笼统的「系统错误」。这六项过完，才算具备上生产的条件。

一万网络能给 PDF 渲染这类突发并发场景接什么：下单前要确认的清单

如果你准备把这套东西落到租用的机器上，下单前建议先把下面几件事问清楚，沟通成本比事后改配置低得多。第一，机器规格里的内存是否可按需上调：渲染负载最常出现的调整就是「文档变重了、并发要降、内存要加」，如果供应商支持平滑升配，你会省掉一次迁移。第二，同一机房内能否开多台并组内网：这是「无认证服务绝不暴露公网」这条铁律能否落地的前提，也是横向扩容能否做的前提。

第三，内网带宽与公网出口的计费方式：大批量渲染会涉及大量文件在内网与对象存储之间流动，走 S3 预签名直取直传时，这部分流量走的是公网还是内网、怎么计费，直接影响成本模型，一定要在下单前问清楚。第四，弹性能力：是否存在按小时或按天计费的临时扩容选项，能否支撑你月末开票、夜间批处理这类明确的尖峰窗口。第五，监控与告警：宿主机层面能提供哪些指标，是否支持你自己部署 OpenTelemetry 采集端。

把这几条问完，你手上的就不是一句「我要一台服务器」，而是一份能直接对上业务形状的需求单——内存档位、实例数量、内网拓扑、弹性窗口、成本口径都清楚了，供应商也更容易给出准确的方案。一万网络深耕 IDC 行业 19 年（成立于 2007 年），在华南、华东、华北及中国香港、海外多地整合自营节点与 BGP 多线资源，提供服务器租用、机柜托管与带宽接入的一体化交付；具体机型、带宽与报价以官网实时信息或咨询确认为准。参考预算请以官网实时报价为准，涉及具体机型与带宽的部分建议直接咨询确认，别拿本文的推算当报价单用——本文给的是选型思路与配置纪律，不是价目表。