PDFMonkey 是很强的 HTML 模板产品
PDFMonkey 不是弱竞争对手。它是一个成熟的托管产品，适合希望用模板、动态数据和自动化工具生成 PDF 的团队。当前文档描述了两条模板路径：可视化 Builder，以及用 HTML、CSS、Liquid 编写的 Code Templates。它还提供 REST API、webhook、无代码集成、文档保留、签名下载 URL 和密码保护 PDF。
这让 PDFMonkey 很适合按 HTML 模板或无代码流程思考的团队。更尖锐的问题是：你的生产 PDF 应该是由 Chromium 渲染的 HTML 文档，还是由 PDF 原生 JSON 契约渲染的结构化业务文档？
30 秒决策
- 事实来源已经是 HTML/CSS、Liquid 模板或无代码自动化？选 PDFMonkey。
- 每个生成文档都需要后台记录和签名下载 URL？选 PDFMonkey。
- 高用量生成结构化发票、物流面单、收据、对账单、票券或电子发票？选 gPdf。
- 一次 API 调用直接返回 PDF 字节流，且默认不做文档持久化？选 gPdf。
- 需要 PDF/A、Factur-X/ZUGFeRD、矢量条码能力或文档权限控制？选 gPdf。
- 默认托管边界必须是 EU Paris？选 PDFMonkey，除非 gPdf 私有部署在范围内。
真正的产品边界：文档应用 vs PDF 基础设施
PDFMonkey 更像带 API 的文档生成应用。你创建模板，创建文档记录，让服务渲染，然后在生成成功后取得签名 URL。当文档生命周期本身很重要时，这很有用：后台审核、文档保留、手动删除、分享链接，以及自动化平台交接。
gPdf 更像 PDF 基础设施。JSON Render 和 Template Render 成功时直接返回 PDF 字节流。默认安全模型对文档内容是无状态的：请求 JSON 只在渲染期间保留在内存里，输出 PDF 流式返回，默认不存储请求正文或 PDF 字节流。
两种模型都合理。它们解决的是不同运营问题。
HTML/CSS 是 PDFMonkey 的天然优势
PDFMonkey 的 Code Templates 使用 HTML、CSS 和 Liquid。这正是很多团队已经熟悉的东西。如果你的发票模板本来就是一个 Web 视图，邮件模板已经是 HTML，或运营团队希望复用 Tailwind 类名和 Web 字体，PDFMonkey 会很自然。
它的可视化 Builder 对非技术用户也有价值。官方文档把它描述为可视化拖拽，学习曲线低于 Code Templates，而且 Builder 和 Code Templates 都通过 Chromium 渲染。对包含页眉、正文、图片、表格和重复区块的常规业务文档来说，这是实用的创作体验。
当 PDF 很接近网页时，HTML 渲染也确实更好：带复杂 CSS 的营销文档、复用现有前端组件的报告、JavaScript 生成图表的文档、重度依赖 CSS 框架的模板，或浏览器模型本来就是事实来源的多页 HTML 布局。gPdf 不试图替代这条流程。
取舍是 Builder 模板和 Code Templates 是两种分离的模板类型。PDFMonkey 文档说明它们不能互相转换。gPdf 走另一条路：可视化编辑器和 API 共享同一套 JSON 底层结构。模板不是一个地方是 HTML、另一个地方是另一种模板表示；它是同一份结构化文档契约，既可以可视化查看，也可以通过 API 发送。
结构化文档是 gPdf 拉开差距的地方
发票、物流面单、收据、对账单、票券、证书和电子发票 PDF 通常不是任意网页。它们是结构化数据、精确位置、页面尺寸、金额合计、条码、元数据和合规规则。
对这类工作负载，gPdf 的 JSON 原生模型更直接。调用方不必为每份文档拼一个完整 HTML 页面，而是可以把 template_id + data 发送到 /api/v1/template-render，或把完整 DocumentRequest 发送到 /api/v1/pdf/render。PDF 层负责页面几何、文字、表格、图片、条码、元数据、安全策略和输出。
在 AI 辅助流程中，这个差异更重要。AI agent 生成并修复符合 gPdf schema 的结构化 JSON，通常比推断一个浏览器渲染的 HTML 页面是否会正确分页、打印或通过条码扫描更可靠。
诚实看成本
PDFMonkey 的公开价格已于 2026-06-04 核对。公开方案从 Free 到 Premium。免费方案每月包含 20 份文档。Starter 为每月 5 欧元，包含 300 份文档。Pro 为每月 15 欧元，包含 3,000 份文档。Pro+ 为每月 60 欧元，包含 5,000 份文档。Premium 为每月 300 欧元，包含 6 万份文档。Pro+ 和 Premium 可用按量付费超量，Premium 超量标价为每个额外文档 0.005 欧元。
如果每月生成 10 万份单页文档，按 Premium 公开标价且不含 VAT 粗略计算约为 500 欧元：6 万份文档的 300 欧元，加上 4 万个额外文档 × 0.005 欧元。
gPdf Basic 是每月 5 美元，包含 10 万页。这就是核心差异：PDFMonkey 按文档生成应用定价；gPdf 按 PDF 生成基础设施定价。
多页文档要重新计算。如果你的平均 PDF 有 N 页，gPdf 用量约为 文档数 × N 页，而 PDFMonkey 的公开模型按文档数计数。单页发票、物流面单、票券和收据最能体现 gPdf 的价格对比；长报告或对账单需要按具体负载计算。
低用量时，两者都可能便宜到架构比价格更重要。高用量的面单、收据、发票和对账单，定价模型会变成架构决策。
数据隐私和保留不是一回事
PDFMonkey 文档明确说明，它会存储 payload 和 meta 字段直到文档被删除，会把生成文件存在私有 S3，并使用短期预签名下载 URL。其安全文档说明数据在传输中加密，动态数据存放在加密数据库列中，生成文件位于私有 S3 bucket，基础设施托管在 AWS EU Paris 区域。
这是可信的托管文档生命周期模型。但它不等同于无状态渲染路径。
gPdf 的默认渲染路径不持久化文档内容。如果你的系统只需要生成后的字节流，并且已经拥有存储、审计日志和交付路径，这会是更干净的边界。如果你的团队希望 PDF 生成产品保留生成后的文档、提供下载链接，并让用户之后查看或删除，PDFMonkey 的模型可能更合适。
失败模式和延迟
两个产品都是托管 API，所以都会引入供应商依赖。差异在执行形态。
PDFMonkey 的 API 创建文档并返回文档对象。生产代码通常轮询状态，或使用 webhook 得知文档何时准备好。这种设计适合异步流程和以后台看板为中心的运营。
gPdf 的 JSON Render 和 Template Render 成功时直接返回 application/pdf。这更适合“用户点击下载发票”的同步流程、仓库流程中的物流面单生成，以及想要简单请求/响应契约的后端。
密码、权限和合规
PDFMonkey 的简单密码路径很强：在文档元数据中传 _password，生成的 PDF 会用 AES-256 加密。文档说明这适用于所有模板、集成和方案。
gPdf 的安全模型更偏策略化。Pro 支持 AES-128 打开密码输出。Enterprise 策略支持 AES-256、所有者密码，以及 print、modify、copy、annotate、fill forms、assemble、high-quality print 等文档权限位。这给采购和合规团队更细粒度的控制，但也有明确分层，并且与 PDF/A 和电子发票模式互斥。
对归档和电子发票流程，gPdf 有更清楚的产品化路径：PDF/A 配置和专用 Factur-X/ZUGFeRD PDF/A-3 路由。本次复核期间，在 PDFMonkey 当前公开文档中未找到可比的公开 PDF/A 或 Factur-X/ZUGFeRD 生成路径。
迁移形态
从 PDFMonkey 迁移到 gPdf，不是逐行把 Liquid 改成 JSON。更好的迁移方式是先识别哪些部分是稳定 layout，哪些部分是可变业务数据。
- // Before: create a PDFMonkey document and poll or wait for a webhook
- const response = await fetch("https://api.pdfmonkey.io/api/v1/documents", {
- method: "POST",
- headers: {
- Authorization: "Bearer PDFMONKEY_SECRET_KEY",
- "Content-Type": "application/json"
- },
- body: JSON.stringify({
- document: {
- document_template_id: "YOUR-TEMPLATE-ID",
- status: "pending",
- payload: {
- invoice_number: "INV-2026-001",
- total: "$240.00"
- }
- }
- })
- });
- const document = await response.json();
- // Later: poll document_cards or receive a webhook, then download the signed URL.
+ // After: render through a shared gPdf template and receive PDF bytes
+ const response = await fetch("https://api.gpdf.com/api/v1/template-render", {
+ method: "POST",
+ headers: {
+ Authorization: `Bearer ${process.env.GPDF_TOKEN}`,
+ "Content-Type": "application/json"
+ },
+ body: JSON.stringify({
+ template_id: "invoice-v2",
+ data: [{
+ invoice_number: "INV-2026-001",
+ total: "$240.00"
+ }]
+ })
+ });
+ const pdfBytes = await response.arrayBuffer();重要变化不是语法，而是产品契约：从存储型文档生命周期，变成直接的 PDF 基础设施调用。
最终选择
如果你的团队已经拥有 HTML/CSS 模板，并且想保留它们，选择 PDFMonkey。当无代码自动化是买方主流程时，选择它。当文档保留、后台审核、签名下载 URL 或 EU Paris 托管是一等需求时，也选择它。业务想要的是一个友好的带 API 的文档生成应用，而不是底层基础设施层时，PDFMonkey 也更合适。
当 PDF 从结构化后端数据生成，并且调用方希望在没有浏览器渲染模型的情况下得到可预测输出时，选择 gPdf。物流面单、发票、收据、仓库文档、对账单、票券、证书和电子发票 PDF 是产品核心。
资料来源说明
PDFMonkey 价格和文档已于 2026-06-04 对照官方 价格页面、Builder vs Code Templates、API PDF generation、security measures、data storage and retention 和 password protection 文档核对。竞品价格和功能页面可能变化，采购团队在做购买决策前应重新核对 PDFMonkey 官方页面。
相关 PDF 生成场景
后续可以按文档类型继续看。结构化数据生成 PDF，先看 JSON 转 PDF API 和 模板 PDF API。如果要落到具体业务场景，可以比较 发票 PDF 生成、物流面单 和 批量 PDF 生成。如果文档合规要求更重，再看 PDF/A API、Factur-X API 和 ZUGFeRD API。
常见问题
gPdf 是 PDFMonkey 的替代方案吗？
是，当目标是通过 API 生成结构化 PDF 时。若 HTML/CSS 模板、Builder 模板、无代码集成、文档保留和签名下载 URL 才是想要的流程，PDFMonkey 仍然是很强的选择。
PDFMonkey 更适合 HTML 模板吗？
是。如果事实来源是 HTML/CSS，PDFMonkey 的 Code Templates 更自然。gPdf 刻意采用 JSON 原生模型，并不试图成为任意 HTML 转 PDF 转换器。
每月 10 万个 PDF 哪个更便宜？
按 2026-06-04 核对的公开标价，10 万份单页 PDF 下，gPdf Basic 为每月 5 美元，包含 10 万页。PDFMonkey Premium 为每月 300 欧元，包含 6 万份文档；启用按量付费后，额外 Premium 文档标价为每份 0.005 欧元。如果你的文档平均超过一页，gPdf 需要按页数重算，PDFMonkey 按文档数重算。
PDFMonkey 会存储文档数据吗？
会。PDFMonkey 文档说明，它会存储 payload 和 meta 字段直到文档被删除，并把生成文件存在私有 S3，直到删除或 TTL 过期。这支持后台看板和下载链接流程。gPdf 的默认渲染路径不持久化请求正文或 PDF 字节流。
gPdf 支持 PDFMonkey 那样的无代码集成吗？
不是同一种产品能力面。PDFMonkey 有 Zapier、Make、n8n、Bubble、Workato 等无代码集成。gPdf 主要是 API 和 Studio 流程，面向希望把 PDF 生成当作基础设施的团队。
电子发票应该用哪个产品？
当你需要通过 API 生成受支持的 Factur-X 或 ZUGFeRD PDF/A-3 打包输出时，使用 gPdf。当你的电子发票需求只是从 HTML 生成可视化发票 PDF，而法定 XML、归档和税务报送由其他系统处理时，使用 PDFMonkey。