Agent Skills
返回列表
📁

Gotenberg 文档转 PDF 转换 API

办公效率 更新于 2026.08.29

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/gotenberg-document-to-pdf-conversion-api 这个技能。

技能介绍

解决什么问题

把 HTML 页面、URL、Markdown 或 Word/Excel 等办公文档变成 PDF，看起来只是"打印成 PDF"，实际在工程上经常很脏：本地渲染依赖浏览器版本，服务端环境缺少字体导致排版漂移，wkhtmltopdf 对现代 CSS 支持有限，不同客户端导出的 PDF 版式不一致，再加水印、合并、加密又得自己拼一堆工具。Gotenberg 把 Chromium、LibreOffice 和 PDF 引擎统一到一个 HTTP API 后面，让文档转换变成一次 POST 请求，而不是维护一套自研流水线。

它如何工作

这个技能指向的是 Gotenberg 的 Docker 化服务，核心能力可以分成三层：

  • 渲染层：HTML/URL/Markdown 走 Chromium 渲染，因此对 CSS 布局、截图、print 样式有比较一致的呈现；办公文档走 LibreOffice 转换，降低不同源文件格式带来的差异。
  • 接口层：所有能力暴露成 HTTP API，调用方不必关心容器里跑的是哪个引擎，也不必在业务服务里嵌入 LibreOffice 或 Chromium 依赖。
  • 后处理层：转换完成后还能继续处理 PDF，例如 合并、拆分、添加水印、编辑元数据、加密，适合把"转换 + 整理 + 交付"串成一步。

典型流程是：准备源文件（HTML 文本、URL、Markdown 或 docx/xlsx 等办公文档）→ 通过 API 发起转换 → 拿到 PDF → 按需执行合并、拆分或水印等后处理 → 输出最终文件。对工程师来说，最大的价值不是多了一个 PDF 工具，而是把渲染环境和文档后处理都收敛到一个可复用的服务里。

适用边界与注意点

  • 这是 Docker-based API，需要容器运行环境。没有 Docker 就跑不起来，部署前要确认目标机器能否起容器、能否访问镜像。
  • Chromium 渲染能力强，但复杂 CSS、字体缺失、异步加载内容仍可能导致和浏览器里看到的效果不一致；办公文档经过 LibreOffice 转换后，排版也可能与原软件中的表现有差异。
  • 后处理能力（合并、拆分、水印、元数据、加密）适合常见文档管理场景，但加密强度、权限控制能否满足合规要求，需要结合具体业务自行验证。
  • API 适合服务端集成，不太适合在用户浏览器里直接完成转换；批量大文件或高并发场景，要考虑容器资源和请求耗时。

一句话说，它适合把"文档转 PDF 并整理交付"从零散脚本换成一个统一 HTTP 服务；不适合用来做无损排版还原或替代桌面 Office 的精确渲染。

参考来源

  • 项目文档：https://gotenberg.dev
  • 上游 SKILL.md 来源：https://github.com/1991513ccie-png/skills
  • Gotenberg 文档摘录：https://raw.githubusercontent.com/gotenberg/gotenberg/HEAD/README.md

使用场景

  • 后端工程师需要把用户提交的 HTML 报告转换为 PDF，并自动加上公司水印和页码后返回下载链接。
  • 系统管理员希望将多份独立的 Word 文档批量合并为一个 PDF 文件，并设置打开密码以限制内部传阅。
  • 前端开发者要将网页 URL 实时渲染成 PDF 归档，同时提取转换后文件的元数据以便后续检索。
  • 运维人员需要将服务器上生成的 Markdown 文档转换为排版一致的 PDF，并通过 HTTP API 接入现有流水线。

适合人员

  • 后端开发工程师：需要在服务端将 HTML 或 Markdown 报告转换为 PDF，并集成水印与加密等后处理能力。
  • 系统架构师：设计文档系统时，需要能统一调度 Chromium 与 LibreOffice 的 Docker API 来处理多源格式。
  • 运维工程师：维护转换微服务时，希望将办公文档转 PDF、合并与拆分封装为标准 HTTP 接口以降低成本。