Stirling-PDF:五十多个 PDF 工具装在自己电脑上,文件一张都不外传

大家好，我是小武！

上个月要发一份采购合同给对方，里面有报价和联系人。发出去之前得把这几处涂掉，再压一压体积，转成 PDF/A 存档。

手边最顺的办法是搜个在线 PDF 工具，拖进去，点两下，下载。文件在别人服务器上停了多久、有没有留副本，我不知道。

Stirling-PDF 就是把这一套搬回自己机器上。开源，9.6 万 star，五十多个 PDF 工具，桌面端、浏览器、自建服务端三种跑法。

打开就是一整间工具房

装完打开，左边一条窄栏放文件，中间是空的工作区，右边一列按用途分好组：

推荐位摆着 PDF 文本编辑器、合并、比较、压缩、转换、OCR 清洗、脱敏、多功能合一。往下滚，签名与证书、文档安全（加密、水印、印章、消毒、解表单、改权限）、验证签名、改元数据，各自成组。

最常用的还是那几个：合并、拆页、压缩、加密码、去密码、加水印、旋转、裁切、加页码、抽图、转图片、图片转 PDF、填表、修复、扫描件拆分、涂黑。

界面有四十多种语言，中文是其中之一。

三种跑法，文件去哪不一样

桌面端装好之后，还要选一种连接方式，这个选择直接决定文件出不出你的电脑。

只用本地：所有工具都在你自己的机器上跑，什么也不上传。碰到本地引擎跑不了的，工具上会挂一个云朵角标，点下去才让你登录或者连服务器。

连云端：能本地跑的就本地跑，跑不了的自动送去 Stirling 的云。手动跑工具不扣额度，AI、处理整个文件夹、流水线这三样走云，扣额度。

连自建服务端：什么都往你的服务器上送，哪怕本机明明跑得动。服务器连不上，才让本地引擎顶上。

哪种必须往外走，文档里列得清楚：OCR、Office 或电子书或网页或邮件转 PDF、PDF 转 Word／PPT／RTF／HTML／Markdown／XML／PDF-A／EPUB／CBR、修复、扫描件拆分、替换并反色，还有压缩里的「转成线稿」。这些要么靠 LibreOffice、Tesseract 这类重家伙，要么靠模型，塞不进桌面端。

起个服务，团队都能用

跑完开 http://localhost:8080，浏览器里就是那间工具房。要给团队用，官方还给了 Kubernetes 和裸 JAR 两种装法，SSO、审计日志、Fail2Ban、多实例都在这条线上。

只是自己用，装桌面端省事，不用碰 Docker。

接进自己的流程：API 和 MCP

服务端每个工具都对应一个 REST 端点，文件用 multipart/form-data 传上去，返回的就是处理好的文件。路径按「分类 / 操作」排：

带 X-API-KEY 头请求，服务端自带 /swagger-ui/index.html，你这个版本有哪些端点、参数长什么样，那里全能试。健康检查是 GET /api/v1/info/status，不校验 key。

再往上一层是 MCP。装好之后 AI 客户端能直接调它的八个工具：查操作参数、页面操作、格式转换、杂项、安全、上传、下载、AI 能力。上传会返回一个 fileId，后面几步复用同一个文件，不用每步重传；返回结果默认内联上限 10 MB，更大的只给 fileId。

它哪些地方要花钱

Stirling-PDF 现在是 open-core，不是整块 MIT。核心是 MIT，app/proprietary/、engine/、编辑器里的几个目录另有许可，云端的额度、AI、流水线按套餐算。自己搭一台服务端跑日常的合并压缩，一分钱不花；想用 AI 助手和自动分类，就得走云。

另外三处容易踩：桌面端选「只用本地」之后，上面那串依赖外部引擎的工具会变灰；大文件吃内存，服务器得给 JVM 留够；合并也不是无损的，签过名的 PDF 处理完签名就失效了。

把它挂在入口上

挨个点按钮终究是手工。真装进系统里，是把它挂在传输入口前头：用户传上来先过一道 /api/v1/misc/compress-pdf，体积降下来再入库存档，后面谁下载都是小的那份。

一个接口、一行请求，比每次打开界面点一遍省事得多。要批量处理一整年的发票，写个循环就完事。