Stirling PDF：把 50 多个 PDF 操作搬进自托管网页，数据不必出内网

结论先行：值不值得自建

如果你每个月要处理几百份以上的 PDF，或者文件涉及合同、病历、设计稿这类不能出内网的材料，Stirling-PDF 是目前最省事的自建方案——一个 Docker 容器，50 多项 PDF 操作，全部跑在本地 CPU 上，不依赖任何外部 API。但如果你一个月也就转三五份文件，别折腾，系统自带的打印成 PDF 加在线工具完全够用，维护一个 Java 容器的成本高于收益。

部署过程实录

环境

$ lsb_release -d && docker -v && free -g | head -2
Description:    Ubuntu 22.04.4 LTS
Docker version 24.0.7, build afdd53b
               total        used        free
Mem:               7           1           5

拉取镜像

$ docker pull stirlingtools/stirling-pdf:latest
Digest: sha256:4e0c1b7a... 
Status: Downloaded newer image for stirlingtools/stirling-pdf:latest

# 耗时 1 分 38 秒，镜像 1.24GB（含 LibreOffice、Tesseract、Ghostscript）

启动容器

$ mkdir -p /opt/stirling/{configs,tessdata,logs}
$ docker run -d --name stirling-pdf \
    -p 8080:8080 \
    -v /opt/stirling/configs:/configs \
    -v /opt/stirling/tessdata:/usr/share/tesseract-ocr/5/tessdata \
    -v /opt/stirling/logs:/logs \
    -e DOCKER_ENABLE_SECURITY=false \
    -e LANGS=en_US,zh_CN \
    -e JAVA_TOOL_OPTIONS="-Xmx2g" \
    --restart unless-stopped \
    stirlingtools/stirling-pdf:latest
7f3c9a2b1e04...

健康检查

$ time curl -s localhost:8080/actuator/health
{"status":"UP"}
real    0m19.4s   # Spring Boot 冷启动，二次重启约 11s

浏览器打开 http://<内网IP>:8080 即可看到完整界面。从零到可用总耗时约 4 分钟，其中 3 分钟在拉镜像。

兼容性实测

性能基准

测试环境：4 vCPU（Xeon Platinum 8259CL）/ 8GB RAM / NVMe SSD / Ubuntu 22.04 / Docker 24.0.7，JVM 堆上限 2GB，单容器单并发（除并发项）。数据为 5 次取中位数。

纯结构类操作（合并/拆分/水印）基本是 I/O 密集，速度很快；OCR 是唯一的性能瓶颈，200 页扫描件要两分多钟，而且会把四核吃满。

资源占用分析

CPU

空闲态 CPU 占用 0.3%。合并、拆分这类操作几乎不占 CPU，单请求约 25%。OCR 是唯一的重负载路径，4 核能跑到 396%，此时如果同时有人点压缩会明显排队。2 核机器跑 OCR 会变成单通道串行，体验很差。

内存

静止 3 分钟后常驻内存 812MB（JVM 基础开销 + Spring 上下文）。压缩 48MB 大文件时峰值 RSS 到 1.86GB。给 2GB 内存的机器跑，必须在启动参数里限制堆（-Xmx900m），否则处理大文件会被 OOM Killer 干掉。

磁盘

镜像 1.24GB；tessdata 全量语言包 4.3GB，只挂 en_US + zh_CN 约 260MB，建议按需挂载；配置和日志目录长期占用 50MB 以内。临时文件在容器内 /tmp，处理超大文件时会短暂占用等量磁盘空间。

配置建议：2C2G 只能当轻量工具用；4C4G 是舒服的起步线；有 OCR 需求直接上 4C8G + SSD。树莓派 4B（4G）能跑，但 OCR 慢到不可用。

成本对比

按每月 10,000 次操作（约 3,000 页 OCR + 7,000 次结构操作）估算，价格随官方调整会有浮动，仅作量级参考。

分水岭很清楚：月操作量超过 800–1,000 次，自建就开始省钱；超过 5,000 次，自建成本只有云 API 的十分之一左右。低于这个量级，云 API 省下的运维时间更值钱。

结论

适合自建：文件不能出内网（医疗、法务、政务、制造业图纸）；月处理量上千份；已经有常开的 NAS 或家里/公司有闲置机器；需要批量 OCR 又不想按页付费。这类场景下 Stirling-PDF 几乎没有替代品——功能密度和部署简便度都明显好于自己拼 Ghostscript 脚本。

别折腾：一个月用不到几十次；不愿意为升级镜像、清理临时文件、盯着 CVE 打补丁投入任何时间；需要精细的内容级编辑（改文字段落、调版式）——Stirling-PDF 是"操作工具箱"而非 Adobe Acrobat 的替代品，复杂排版修改仍然得靠桌面软件。

还有个容易被忽略的点：它是 Java 应用，冷启动接近 20 秒。如果你打算做成 Serverless 按需拉起，这个启动时间会很致命，老老实实常驻一个容器更合适。