Stirling PDF：自建 PDF 工具箱
摘要
PDF 合并、拆分、压缩、转图片，这些需求不高频，但每次要用时都让人头疼：在线工具要上传文件（隐私呢？）、本地软件要装要收费。自建 Stirling PDF，一次部署， permanent 解决：CT702 上 Docker 跑起来（内网 :8080），50 多个 PDF 操作全免费、无文件大小限制、文件不出内网。这篇记录部署过程、常用功能速查、和本地/在线工具的对比，以及"大镜像拉取"这个部署时的真实坑。
目录
- 一、为什么自建 PDF 工具箱
- 二、部署：CT702 上的 Docker
- 三、功能清单：50 多个操作，常用速查
- 四、上手：三个最高频操作
- 五、和本地工具、在线工具的对比
- 六、纯内网：文件不出家门
- 七、踩坑记录
- 八、总结
一、为什么自建 PDF 工具箱
PDF 工具的需求曲线很典型：平时想不起来，一用就是急活——报销要合并发票、合同要拆分章节、扫描件太大要压缩。三个选项：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 在线工具（iLovePDF 等） | 打开即用 | 文件要上传到别人服务器，隐私裸奔；免费版限大小、限次数 |
| 本地软件（Adobe 等） | 功能强 | 贵；重；手机上不方便 |
| 自建 Stirling PDF | 免费、无限制、文件不出内网、手机浏览器也能用 | 要自己部署一次 |
对"偶尔用、但用时很急"的场景，自建是最优解。部署一次，之后每次用就是打开浏览器。隐私是决定性因素：合同、发票、证件扫描件，传到第三方服务器上转一圈，想想都不踏实。
二、部署：CT702 上的 Docker
Stirling PDF 跑在 CT702（docker-lab）上，和 Uptime Kuma、Dashy 共用 /root/lab-compose.yml（在容器内）：
# /root/lab-compose.yml（stirling-pdf 片段，结构示意）
services:
stirling-pdf:
image: stirlingpdf/stirling-pdf:latest
ports:
- "8080:8080"
volumes:
- /opt/stirling-pdf/training:/usr/share/tessdata # OCR 语言包（可选）
内网访问 http://192.168.0.127:8080，首页返回 200 即部署成功。数据是无状态的（处理完即走，不存文件），所以不需要操心数据卷备份，这是它和博客、密码库最大的不同。
部署时的真实坑是镜像拉取：Stirling PDF 镜像约 1.1G，家里直连 Docker Hub 极慢，ghcr.io 甚至 DNS 不可达。当时用 crane 在本机拉包、按 200M 分片经 VPS 中转、最后 docker load 导入，完整过程见《内网拉镜像太慢？crane 分片中转 + xray 代理双方案》。后来给 CT702 配了 xray 代理，一劳永逸。
三、功能清单：50 多个操作，常用速查
Stirling PDF 的功能多到一屏放不下，按场景分组，常用的其实就这几个：
| 场景 | 功能 | 说明 |
|---|---|---|
| 合并 | Merge PDFs | 多个 PDF 合成一个，可调顺序 |
| 拆分 | Split PDF | 按页码范围、按固定页数、按书签拆 |
| 压缩 | Compress PDF | 降画质压体积，发邮件前必备 |
| 转换 | PDF 转图片 / 图片转 PDF | 扫描件、报销单常用 |
| 页面 | 旋转、删除、提取页面 | 调整页面方向、删空白页 |
| 安全 | 加密码、去密码、加水印 | 基础加密，不是高强度 |
| OCR | 图片型 PDF 转可搜索 | 需要 OCR 语言包 |
不常用的还有一堆：PDF/A 转换、元数据编辑、签章、表单处理……知道"它有"就行，用到时再翻。Stirling PDF 的界面是按功能平铺的，搜索框直接搜关键词，比翻菜单快。
四、上手：三个最高频操作
合并：报销发票打包
- 打开 Merge PDFs，拖入多个 PDF；
- 拖拽调整顺序；
- 点合并，下载。完事。
拆分：合同按章节分
- 打开 Split PDF，上传文件；
- 选"按页码范围"，填比如 1-5, 6-12；
- 下载拆好的多个文件。
压缩：扫描件太大发不出去
- 打开 Compress PDF，上传；
- 选压缩强度（一般选中等）；
- 下载，看体积从几十 M 降到几 M。
三个操作都是"上传 - 点一下 - 下载"三步，没有学习成本。家里人也能用，这是自建工具箱的重要指标：不只自己用得爽，家人急用时也能自己搞定。
五、和本地工具、在线工具的对比
| 维度 | Stirling PDF（自建） | 在线工具 | 本地软件 |
|---|---|---|---|
| 隐私 | 文件不出内网 | 上传到第三方服务器 | 文件在本地 |
| 费用 | 免费 | 免费版限功能/大小 | 收费或找破解 |
| 文件大小限制 | 无（看服务器资源） | 普遍有限制 | 无 |
| 多端 | 浏览器即用，手机也行 | 浏览器即用 | 要装客户端 |
| 部署成本 | 一次 Docker 部署 | 零 | 安装配置 |
| 断网可用 | 内网可达就行 | 不可用 | 可用 |
结论：日常 PDF 处理，Stirling PDF 全覆盖；超大文件、批量自动化，还是本地工具（pdftk、Ghostscript 命令行）更合适；出门在外借别人电脑，在线工具应急。三个各有位置，不互相替代。
六、纯内网：文件不出家门
按用户规则，Stirling PDF 纯内网：只有 http://192.168.0.127:8080，没有公网域名，nps 隧道和公网站点已删。这对 PDF 工具是天然合适的——处理的文件经常是合同、发票、证件，纯内网等于多了一层隐私保障。
在家用，打开浏览器就能处理；在外需要用，连 VPN（WireGuard）进来。Dashy 导航页录了它的内网入口，找起来方便。
七、踩坑记录
坑 1：镜像 1.1G，家里拉不动
Stirling PDF 镜像约 1.1G，是 CT702 上最大的镜像。当时用 crane 拉包 + 200M 分片 + VPS 中转 + docker load，人肉搬运。教训：大镜像部署前先看家里网络行不行，不行就提前准备中转方案，别等 docker pull 卡住了再想办法。
坑 2：OCR 需要额外语言包
OCR 功能默认只有英文语言包，中文 OCR 要挂载 tessdata 中文包。部署时如果没配，用到中文扫描件才发现，等于功能残废。按需挂载：/opt/stirling-pdf/training 映射到容器内 tessdata 目录，中文包丢进去。
坑 3：处理大文件时内存
CT702 只有 3G 内存，Stirling PDF 处理几百 M 的 PDF 时，JVM 堆可能吃紧。大文件处理前看一眼容器内存，必要时给 compose 加 mem_limit 保护，避免把整台容器的内存吃光影响其他应用。
OCR 实战：扫描件变可搜索
Stirling PDF 的 OCR 能把图片型 PDF（扫描件、拍照的文档）转成可搜索的文字层。注意两点：
- 中文要挂语言包：默认只有英文，中文 OCR 把 tessdata 中文包挂到
/opt/stirling-pdf/training（见部署节）； - OCR 是"加文字层"，不是"转纯文本"：原图保留，文字可选中、可搜索，排版不变。
流程：打开 OCR 功能 → 上传扫描件 → 选语言（中文）→ 下载。发票、合同扫描件走一遍 OCR，以后搜关键词直接定位，不用一页页翻。
命令行替代：批量处理
Stirling PDF 是"一次处理几个文件"的交互工具，批量（几百个文件）还是命令行靠谱：
| 需求 | 工具 | 例子 |
|---|---|---|
| 批量合并 | pdftk | pdftk *.pdf cat output merged.pdf |
| 批量压缩 | Ghostscript | gs -sDEVICE=pdfwrite -dPDFSETTINGS=/ebook -o out.pdf in.pdf |
| 批量转图片 | pdftoppm | pdftoppm -png doc.pdf page |
分工：日常随手用 Stirling PDF，写脚本批量用命令行。两个都会，PDF 就没有难办的事。
纸质到数字：家庭文档数字化的流水线
Stirling PDF 是"纸质→数字"流水线里的一环。完整的家庭文档数字化是这样的：
第一步：扫描/拍照。 手机扫描 App（或扫描仪），纸质合同、发票、证件，变成图片或 PDF。这一步的关键是"命名规范"：2026-10-01_电费发票.pdf，日期开头，内容其次。命名规范是数字化的地基，名字乱了，后面全乱。
第二步：OCR。 图片型 PDF 走 Stirling PDF 的 OCR，加中文文字层，变成可搜索的。这一步的价值：以后找"2025 年的物业费发票"，搜关键词就行，不用一页页翻。
第三步：整理归档。 按"证件/财务/合同/其他"分文件夹，存在 NAS 上。NAS 的快照开着，误删能找回。这一步和 OpenList 的 /归档 卷衔接：归档好的文件，只读分享给家人。
第四步：原件处理。 数字化后，纸质原件别急着扔。发票、合同这类有法律效力的，先确认电子版清晰可读，再按"重要程度"决定原件去留。身份证、房产证这种，原件永久保留，电子版只是"方便查"。
流水线跑起来，家里的纸质文件越积越少，找东西从"翻箱倒柜"变成"搜关键词"。Stirling PDF 在其中的位置是"加工站"：合并、拆分、压缩、OCR，纸质变数字的过程中，所有"动手脚"的活都在这干。工具的价值不在工具本身，在它嵌入的流水线。
无纸化办公的另一面：电子签名的坑
PDF 工具箱配齐了，无纸化还差最后一环：签名。Stirling PDF 有"签章"功能，但这里有个大坑要提前说：电子签名 ≠ 图片贴个章。
| 方式 | 效力 | 场景 |
|---|---|---|
| 图片签名（贴个手写签名图） | 无法律效力，防君子不防小人 | 内部流程、示意 |
| 可靠电子签名（国标） | 有法律效力 | 合同、法律文件 |
Stirling PDF 的签章，属于"图片签名"这一档：把签名图片贴到 PDF 上。它解决的是"流程"问题（对方要个签了名的 PDF），不是"法律"问题（打官司认不认）。分清这个边界：内部报销、快递单，图片签名够了；劳动合同、购房合同，老老实实走可靠电子签名平台（e 签宝、法大大）或纸质。
图片签名的正确姿势：签名图片用透明底 PNG，别用白底 JPG（贴上去一个白框，丑）；签完 flatten（压平），别留可编辑的签名域（否则对方能把你的签名抠下来贴到别的合同上）。安全习惯：签名图片别乱发，它是你的"数字笔迹"。
无纸化的全景：扫描归档（Stirling PDF）→ 日常签署（图片签名）→ 重要合同（可靠电子签名平台）。三档分开，别用一档的工具干三档的事。
PDF 的元数据：别泄露隐私
PDF 里藏着元数据：作者、创建时间、修改软件，甚至编辑历史。合同、简历，发出去前，元数据最好清一清。Stirling PDF 有"元数据编辑/清理"功能，发外部前过一遍。
元数据泄露的经典案例：简历的"作者"是上家公司的电脑名，合同的"创建时间"暴露了谈判时间。不是什么大事，但"能清就清"，举手之劳。隐私保护在细节里：文件名别带身份证号，元数据别留真名，对外发的 PDF，清一遍再发。Stirling PDF 的元数据清理，就是干这个的，5 秒钟的事。 工具箱的意义，是"要用时有"。Stirling PDF 在内网待命，就是这句话的落地。别等要用时才装，装好放着，就是它的工作。内网地址记在导航页，要用时点一下就行。PDF 处理不求人，不求外网，不求订阅。这就是自建的快乐：一个 docker 容器，解决一类问题。快乐很简单，容器跑起来就行。跑起来，放着，用的时候点一下。这就是内网工具该有的样子。 Stirling PDF 的 API 也值得一提：它有 REST API，可以脚本化调用。比如"每天凌晨把扫描目录的 PDF 自动 OCR"，写个 cron + curl 就行。API 的玩法，把"工具"变成了"流水线的一环"。这篇讲的是手动用，API 是自动化的门。有兴趣的，可以看它的 API 文档，从"合并两个 PDF"开始试。工具的上限，往往在 API 里。手动用是起点，API 是天花板。天花板有多高，看你的脚本写多勤。脚本写起来，Stirling PDF 就从工具变成了流水线。
八、总结
Stirling PDF 是"部署一次、永久省心"的典型：Docker 一把梭，50 多个 PDF 操作全免费、无限制、文件不出内网。纯内网部署，隐私拉满。三个最高频操作（合并、拆分、压缩）都是三步完成，家里人也能用。和在线工具、本地软件不是替代关系，是互补：日常用它，批量自动化用命令行，大文件用本地。部署时的镜像拉取坑，xray 代理已经一劳永逸解决。
相关阅读：《内网拉镜像太慢？crane 分片中转 + xray 代理双方案》、《PVE 里跑 Docker：LXC 容器 CT702 实战》。
