给合同签字还要上传网站?试试把 PDF 工具留在自己电脑

Stirling-PDF：签名不是一回事，免费也有使用边界

签一份租房合同、合并几张报销发票、把扫描件压小一点——这类事现在大多在浏览器里完成：打开某个在线 PDF 网站，把文件拖进去，处理完再下载。方便是真方便，可文件也确实从别人的服务器上过了一遍。合同、工资单、身份证复印件上传一次，它被存多久、存到哪，你并不知道。

想把这个环节搬回自己的机器，Stirling-PDF 是绕不开的一个项目。它在浏览器里用起来和那些在线工具几乎一样，区别是整件事跑在你自己的服务器或者电脑上——官方 README 的定位就是「不用把文档发给外部服务，就能编辑、签署、涂黑、转换和自动化 PDF」。

项目地址：https://github.com/Stirling-Tools/Stirling-PDF

官网与在线体验：https://stirling.com 、https://stirling.com/app

文档站：https://docs.stirlingpdf.com

先说身份，因为中文资料里踩坑最多的地方就在这。仓库快照（2026-10-12 GitHub API 实测）：94,021 stars、11,132 forks、315 位贡献者、190 条 release 记录（189 条是应用本体，1 条是 Helm chart）；仓库 2023-01-27 创建，归组织 Stirling-Tools 所有，维护者 Frooodle 至今仍活跃在提交署名里。Docker 侧两个官方镜像仓库累计拉取约 3,800 万次（stirlingtools/stirling-pdf 15,954,124 次 + 历史仓库 frooodle/s-pdf 22,414,132 次）。

最新正式版是 v3.1.0，GitHub 上的发布时间是 2026-10-05（UTC），换算北京时间是 10 月 6 日清晨。这一版的标题里带着两个新东西：Stirling Sign 群签转正，以及 beta 阶段的 Stirling Office Convert 转换引擎。

还有一条老命名要提醒：网上很多教程里写的 frooodle/s-pdf、容器名 s-pdf，属于历史命名，现在官方主名是 stirlingtools/stirling-pdf；讲「配置靠 customFiles/templates/ 模板」的教程停留在 v1 时代，v1 到 v2 有破坏性变更。

这是全文最需要掰清楚的地方。Stirling-PDF 里的「签名」实际上是三件不同的事：贴一张签名图的可见签名、能证明签署人身份的数字证书签名、把文件发给多人依次签的签名会话。混着写一定出错。另外还有三个和证书签名配套的工具（验签、时间戳、移除签名），常被单独列成一项，其实它们是证书签名的收尾环节，本文归到证书签名那一类里一起讲。

第一种：Sign（可见签名）。官方文档的原话是「adds a visible signature only, which anyone can copy」——它只是把一张签名图贴到 PDF 上，不提供身份证明，也防不住篡改，谁都能照着复刻一份。创建方式有四种：鼠标或手写笔画、打字选字体、上传图片（自动去白底）、以及扫二维码在手机上手写再回传。登录后最多保存 20 个签名；未登录最多 10 个，而且只存在当前浏览器里。免费。

第二种：Sign with Certificate（证书签名）。这才是真正的数字签名：能证明是谁签的，也能在事后发现文件有没有被改过。证书来源三选一——上传自己的 PKCS12/PFX、PEM 或 JKS 文件；用服务器上管理员配好的组织证书（需要登录）；或者用桌面端本机的 Windows 证书库、USB 令牌和智能卡。签名外观可以是不可见，也可以做成带证书名、日期和 reason 的可见签名框。

两个使用细节官方写得很明确：过期或尚未生效的证书会被直接拒绝；自签名证书在阅读器里会显示「未验证」。想证明「什么时候签的」，签完再用 Timestamp PDF 打一个时间戳。

证书签名旁边有三个配套工具，功能上属于同一件事的收尾：Validate PDF Signature 验签，会给每个签名返回 Valid、Valid, signer not verified、Invalid 三种状态之一，结果能导出成 PDF 报告、CSV 或 JSON；Timestamp PDF 走 RFC 3161 可信时间戳，默认用 DigiCert，服务器只把文档的 SHA-256 哈希发出去，可选白名单里还有 Sectigo、SSL.com、FreeTSA 等；Remove Certificate Sign 用来移除数字签名以便继续编辑。这三件事加上证书签名本身，免费档就能用。

第三种：Stirling Sign（群签 / 签名会话）。 这是 v3.1.0 的主角，也是中文文章最容易照着抄错的一块。它把一个 PDF 发给组织内的多人依次签署，带会话追踪、邮件邀请和一套全新的签名 UI。它在 v2.9.0 时还是 alpha、默认关闭，到 v3.1.0 才转正，并对新用户默认开启。

群签有两个硬边界，第二个几乎没人写对：

其一，它要求真实登录用户。前端对游客直接判定为不可用，后端接口也只放行人类账号，因此没有登录体系的构建（latest-ultra-lite 镜像、两个不带登录的 JAR）拿不到群签。

其二，群签会话里，参与者用自己的个人证书签名时可能被拒。服务端会校验证书类型：参与者选「自己的证书」而服务器没有相应付费许可时，接口返回 403「Personal signing certificates require a Pro license」；源码里能确认的判断条件是「是否运行在 SERVER 或 ENTERPRISE 许可等级」（许可枚举为 NORMAL / SERVER / ENTERPRISE）。两点必须说清：这条限制只针对群签会话中的个人证书，跟前面「上传证书签名」无关——证书签名工具本身在免费档就能用；用组织/服务器证书的参与者也不受这条限制。另外，「SERVER 许可就等于文档里的 Team 档」只是推断，官方文档里有被下架的 Server plan 历史，但找不到一句直接等同的说明，本文按源码里的许可等级写，不写成确定的产品档位对应。

还需要如实说明来源：官方文档站目前没有群签的用户指南，旧链接已经重定向到别的页面；上面这两条来自官方 v3.1.0 / v2.9.0 的 Release 正文，以及调研日（2026-10-12）读取的 main 分支源码。该项目 main 分支在 v3.1.0 发布后仍在更新，这些源码行为不能断言为 v3.1.0 标签之内独有。所以本文也不写群签的界面操作步骤——那部分没有可核验的材料。

官方文档的计划表把界限划得比传言干净得多。全部 PDF 工具、REST API、OAuth2 / OIDC 单点登录、服务器证书签名，在 Free、Team、Enterprise 三档里都标「有」。免费档的用户数是 5 个——注意这是计划表上的功能上限，它只说免费档能建几个用户，不等于「5 人以内怎么用都不涉及许可」。

付费档解锁的是部署与治理能力：用户数扩到 100 起（Team）或按合同（Enterprise）、外部数据库与集群、S3 或数据库的文件存储、Prometheus 指标、自定义 PDF 元数据、SAML 单点登录、审计日志与用量分析、离线激活用的证书文件。换句话说，钱不是花在「用工具」上，而是花在「把它当组织级基础设施用」上。

真正会「用完」的东西是自动化额度。两条规则要分清：

• 手动在界面点工具永远不计费，也不限量。官方原话是「Using the tools by hand never counts」，v3.0.0 的 Release 正文也写了「正常的 PDF 编辑器使用保持免费且不限量」。
• 会消耗额度的是四类调用：Processor 流程与策略；Pipeline API 与 MCP 工具调用；AI 工具；以及用 API key 发起的 PDF 工具调用。它们共用同一份额度，一个文件按「每 25 页」或「每 5 MB」取更大的那个计 1 单位，单文件最多计 1,000 单位——所以「单位」不是「PDF 份数」，一个文件可能是好几个单位。

额度怎么算，取决于你的服务器绑没绑云、有没有相应许可，不是简单的「云端 / 自建」二分：

• 未绑定云的自建服务器：1,000 单位/月，额度用完后自动化、AI 和 API 调用一并停止，手动点工具照常。
• 绑定 Stirling Cloud 团队后：改用团队的额度与计费规则（v3.0.0 的 Release 正文当时说绑定能额外拿 500 份/月，文档现在的口径是「换成团队的额度」，以文档为准）；连续 3 天无法与云确认计划时，绑定带来的功能和处理会暂停。
• 持 Team 许可密钥：API 工具调用不计额度；持 Enterprise 许可：不计额度。
• 在 Stirling Cloud 上跑自动化：消耗的是团队额度，超出后接口返回 HTTP 402，这是另一套账，别和自建服务器的 1,000 单位混着算。

许可证也要说准：Stirling-PDF 是 open-core，不是纯 MIT。根目录 LICENSE 正文是 MIT（版权方 Stirling PDF Inc.），但开头明确排除 9 个目录（app/proprietary/、app/saas/、engine/，以及 frontend/editor/src/ 下的 proprietary、desktop、saas、cloud、portal、portal-saas），这些目录各自挂「Stirling PDF User License」（https://github.com/Stirling-Tools/Stirling-PDF/blob/main/app/proprietary/LICENSE ）。GitHub API 把它的 license 显示为 NOASSERTION，正是这个复合结构导致的。

这份专有许可里有两条最要紧：「生产、规模化或业务关键场景使用，只有持有效许可才是被允许的」；明文允许不付费的范围是内部试用、评估或最小化使用，且不得用于面向客户的商业场景，修改版也不得用于生产或分发。条款划的是范围，不是逐项清单。落到具体用法上，判断得自己对着条款做：

• 内部试用、评估或最小化使用在明文允许的不付费范围内；但这三个词在条款里没有进一步定义，能不能归到这一档，取决于你的实际用法是不是真的只是试用、评估或最小化。
• 生产、规模化或业务关键流程使用，条款要求持有效许可；算不算这一档，同样按实际用途核对，而不是看它表面上像不像「日常」。
• 本文不替读者判定某个用法属于哪一档：把实际用途（谁在用、处理什么文件、面向谁、规模多大）对着条款逐条比对；比对完仍拿不准，就通过官方渠道向官方确认授权口径，别按二手说法下结论。
• 所以「完全开源随便用」不准确，「闭源收费软件」也不准确；「装起来不花钱」和「用起来不需要许可」是两件事。

至于价格，官方公开定价页是产品线口径：云端 Editor 免费、Processor 按处理的 PDF 数量计费、Enterprise 定制；自建服务器那套 Free / Team / Enterprise 的价格没有在这页列出来。所以本文不给任何具体价格数字，需要就去看 https://stirling.com/pricing 。

官方推荐 Docker，一份 compose 加几个挂载目录就能跑起来。这是个最小可用版本：镜像锁到版本号，两个必须持久化的目录加上签名目录，再设上内存上限。

services:

　stirling-pdf:

　　image: docker.stirlingpdf.com/stirlingtools/stirling-pdf:3.1.0

　　container_name: stirling-pdf

　　ports:

　　　- '127.0.0.1:8080:8080'

　　volumes:

　　　- ./stirling-data/configs:/configs

　　　- ./stirling-data/storage:/storage

　　　- ./stirling-data/customFiles:/customFiles

　　mem_limit: 4g

　　restart: unless-stopped

把这段存成docker-compose.yml，在同一个目录执行：

docker compose up -d

然后浏览器打开http://localhost:8080 ，用 admin / stirling 登录，首次登录会被强制改密码，至少 8 位。想自己定首个管理员账号，可以在首次启动前设 SECURITY_INITIALLOGIN_USERNAME / SECURITY_INITIALLOGIN_PASSWORD。

两个提醒：

• 上面把端口绑在127.0.0.1 上，只允许本机访问，适合单机自用。要让同事一起用，就得放开监听或走反向代理，那时先把鉴权和 HTTPS 想清楚：反代要传 X-Forwarded-Proto/Host/Port，上传体积放到 system.fileUploadLimit（默认 2000 MB），读超时给到 30 分钟，并且设好 system.backendUrl / system.frontendUrl，否则邀请邮件、分享链接和手机扫码签名里的地址都会不对。
• 官方 compose 还挂了 /logs、/pipeline、/usr/share/tessdata，分别是日志、文件夹扫描和 OCR 语言包，用得上再加。/configs（设置、内置数据库、生成的密钥）和 /storage（用户存在服务器上的文件）是必须挂的两项，要做签名共享再加 /customFiles。

真要选，是选镜像档位：

镜像标签、登录与管理设置、包含什么、官方建议内存；latest、有、LibreOffice、Tesseract、OCRmyPDF、Calibre、Ghostscript 等转换与 OCR 全家桶、4 GB；latest-fat、有、在 latest 基础上再带内置 AI 引擎（默认关闭）、6 GB；latest-ultra-lite、无、只有核心 PDF 工具，没有 OCR 和 Office 转换、2 GB

先给结论：想要服务器签名库和群签，只能用前两档。latest-ultra-lite 没有登录体系，也就没有服务器签名库和群签。

版本别偷懒用latest：项目 2026 年基本每月发 2 到 8 个版本，官方也给了版本号标签（如 3.1.0、3.1.0-fat），锁定版本更省心。不走 Docker 的话，JAR 路线需要 Java 25（v1 时代是 Java 17，这是官方点名的升级坑）；Kubernetes 有官方 Helm chart，但文档明确提示 chart 默认镜像是旧版本，要手动把 tag 写成 3.1.0 这种。

反代默认 1 MB 上限。 官方 FAQ 专门解释过：上传大文件却下载到一个 .htm 文件或者直接失败，就是反向代理的默认体积限制造成的。官方给的 nginx 示例是 client_max_body_size 2000M;，读取超时 1800 秒。

不给容器设内存上限。 PDF 处理很吃内存，单个大文件的开销可以是文件体积的数倍；容器不设上限时，JVM 会按宿主机总内存来定堆大小。所以务必设 mem_limit，必要时再用 JAVA_CUSTOM_OPTS 把堆比例降下来（注意别用 JAVA_TOOL_OPTIONS，镜像会覆盖它）。

不配 `frontendUrl` 会出一堆奇怪的链接。手机扫码签名的二维码、分享链接、邀请邮件里的地址，都从这个配置取值，填错了对方就打不开。

还有一条给内网和纯离线部署的提醒：吊销检查（OCSP/CRL）、Adobe 与欧盟的信任列表下载、TSA 时间戳，都需要出网，而吊销检查默认是关闭的。内网可以自建时间戳服务并加进白名单，但默认那套公网 TSA 列表在离线机房里是用不了的。

适合：手头有一台 NAS、小主机或软路由，习惯用 Docker 部署服务的人；经常要处理合同、发票、扫描件，又不想把它们传给第三方网站的场景。免费档能建到 5 个用户，功能上够用，装起来的成本也就是一份 compose——但功能免费不等于用途免费，把它接进日常业务处理之前，先按上面的许可条款核对自己属于哪种用途。

不太适合：完全不碰命令行、只想点开网页就用的人——它的价值恰恰在自建，装不起来就用不上。以及需要法律级电子签名的场景：这类需求要的是实名认证加第三方存证，Stirling-PDF 是工具，不提供身份核验和存证服务，自签名证书在阅读器里就显示「未验证」。需要 SAML、审计日志、集群却不打算付费的团队，也不合适，因为这些正是付费档的内容。

最后交代一句本文的边界：所有事实来自官方仓库、Release 正文、官方文档仓库源文件与官方源码，访问时间为 2026-10-12，没有做任何人工实测——没装、没截图、没跑工具。项目月均好几个版本，发文前值得再刷一次 release 页面。

• 仓库与元数据（2026-10-12 GitHub REST / Search API 实测）：https://github.com/Stirling-Tools/Stirling-PDF
• v3.1.0：https://github.com/Stirling-Tools/Stirling-PDF/releases/tag/v3.1.0 ；v3.0.0：https://github.com/Stirling-Tools/Stirling-PDF/releases/tag/v3.0.0 ；v2.9.0：https://github.com/Stirling-Tools/Stirling-PDF/releases/tag/v2.9.0
• 根许可（MIT）：https://raw.githubusercontent.com/Stirling-Tools/Stirling-PDF/main/LICENSE ；专有许可（Stirling PDF User License）：https://github.com/Stirling-Tools/Stirling-PDF/blob/main/app/proprietary/LICENSE
• 群签许可判断源码（调研日 2026-10-12 读取的 main 分支）：https://github.com/Stirling-Tools/Stirling-PDF/blob/main/app/proprietary/src/main/java/stirling/software/proprietary/workflow/service/WorkflowSessionService.java
• 官方计划与许可：https://docs.stirlingpdf.com/Server/Licensing/Plans-and-Licences
• 自动化额度与云绑定：https://docs.stirlingpdf.com/Server/Licensing/Connect-to-Stirling-Cloud
• 签署（用户向）：https://docs.stirlingpdf.com/Tools/Security/Sign 、https://docs.stirlingpdf.com/Tools/Security/Certificate-Signing
• 签署（服务端配置）：https://docs.stirlingpdf.com/Server/Security/Signing
• 安装与运维：https://docs.stirlingpdf.com/Server/Install/Docker 、https://docs.stirlingpdf.com/Server/Install/JAR 、https://docs.stirlingpdf.com/Server/Install/Kubernetes 、https://docs.stirlingpdf.com/Server/Production 、https://docs.stirlingpdf.com/Server/Operations/Performance
• 官方定价页：https://stirling.com/pricing

我是比特小窝，长期关注开源工具与实用技术。

如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。

THANKS FOR READING