两份扫描件要合并，PDF 页序要调整，文件太大又传不上去。这类工作看起来简单，每次却要找不同工具，重新上传文件，再判断输出是不是完整。
Stirling PDF 把常见 PDF 操作集中到一个 Web 界面，能在 VPS 上通过 Docker 运行。适合需要重复处理文档、希望自己管理服务的人。它不代表所有处理都会保留原文件的全部特征，合并、压缩、OCR 和格式转换都应根据用途验收输出。
先用不含私人信息的小文件试用，走完上传、处理、下载和清理，再决定是否长期使用。
第一批测试文件要有不同类型
准备一份可选中文字的 PDF、一份纯扫描图片 PDF，以及一份含横竖页面的多页 PDF。它们分别帮助验证文本处理、OCR 和页面操作。不要只拿一张空白 PDF 测试，然后认为所有文件都能处理。
如果文件有签名、特殊表单或保护设置，转换可能影响原有结构。处理前保存原文件，输出使用新名字；需要保留特殊属性时，先核对对应功能的行为。页面看起来相同，并不说明内部信息完全一样。
VPS 的磁盘和内存要留出处理空间。上传文件大小只是输入大小，转换过程还会产生临时数据。大量扫描页、OCR 和并发任务可能消耗更多资源，小内存服务器应先验证单个任务，不能凭安装镜像启动成功推断处理容量。
当前官方镜像与老教程不一样
以当前 Docker 安装指南为准，官方提供标准、Fat 和 Ultra-Lite 等镜像类型。选择取决于所需工具与依赖，不能把更小镜像直接理解成包含同样功能、只是启动更快。
下面从标准镜像开始。VPS 已有 Docker 与 Compose，在独立目录创建配置：
mkdir -p ~/stirling-pdf/configs ~/stirling-pdf/logs
cd ~/stirling-pdf
services:
stirling-pdf:
image: docker.stirlingpdf.com/stirlingtools/stirling-pdf:latest
ports:
- "127.0.0.1:8080:8080"
volumes:
- ./configs:/configs
- ./logs:/logs
restart: unless-stopped
/configs 保存设置与相关数据库状态，不能在升级时当临时目录删除。初次试用使用官方镜像标签，确定需要的版本后固定核实过的标签或摘要。不要把另一篇文章里的旧镜像名和环境变量拼到一起。
docker compose config --quiet
docker compose up -d
docker compose logs --tail=100 stirling-pdf
ssh -L 18080:127.0.0.1:8080 user@your-server
打开本机 http://127.0.0.1:18080。当前安装指南说明默认启用登录，初始账号为 admin、密码为 stirling，应在私人入口首次登录后立即修改。不同版本的初始化可能变化，实际部署时重新核对所用版本文档，不能长期依赖演示凭据。
不要为了绕过初始化问题关闭登录，再把服务放到公网。先检查日志与配置，完成自己的账号设置后再安排公开域名。
第一次合并，重点看页序和方向
把两份小 PDF 合并，明确选中的先后顺序，下载后从头翻到末尾。检查页面数量、横向页方向以及第一页和最后一页，尤其留意文件选择顺序是否按预期生效。
页码不是文件名中的编号。一个名为“材料2.pdf”的文件可能包含五页，合并后排列仍取决于任务设置。需要抽取或重排时，先用少量页面验证页码规则，避免在正式文件里少一页却不容易发现。
旋转扫描页时也检查文字方向与纸张方向。有时页面显示为竖向，但内容本身横着，操作应针对真实问题。处理后换一个 PDF 阅读器打开，可以更容易发现只在某个预览环境中正常的输出。
重要材料保留原版、处理版和用途说明，不必堆一串“最终版”文件名。比如 meeting-notes-source.pdf 与 meeting-notes-merged.pdf，能帮助以后理解哪份经过处理。
压缩结果不能只看小了多少
压缩后的文件变小，可能来自图片降采样、重编码或其他结构处理。选择设置前先想清用途：屏幕阅读、打印、长期保存，对画质的要求不同。
输出后放大检查小字、印章、表格线与图片细节，再核对页数。若为了降低体积已经让扫描文字难辨认，就不适合继续作为主要存档。保留原文件，发送时使用压缩副本更容易回退。
只有文字的 PDF 和大量扫描图的 PDF，压缩空间可能不同。不要用一个文件的结果给所有文件下“能压缩八成”之类结论。实际结果由内容与设置共同决定。
目标平台有大小限制时，在质量可接受的前提下逐步调整。达到限制后停止继续压缩，不必追求最小数字。文件小到能上传，仍需确认接收方能正常打开。
OCR 先解决语言和输入质量
扫描 PDF 中的文字只是图像，OCR 会尝试生成可检索文本。是否包含中文、英文或混合语言，会影响语言包和设置。需要的语言模型应按当前项目文档与相应官方来源准备，放到正确挂载位置；不要仅修改界面语言就认为 OCR 已支持中文。
先选一页文字清楚的扫描件，确认能选中或检索文字，再试倾斜、低对比度和表格较多的页面。识别结果要人工核对，特别是数字、姓名、日期与单位。OCR 不应被当成经过校验的数据输入。
扫描质量较差时，重新获得清晰源文件常比反复提高识别参数更有效。过度压缩后再做 OCR，也可能让字形进一步模糊。保留原始扫描件，并安排处理顺序。
若镜像类型没有所需转换工具或语言资源，日志通常比界面转圈更能解释原因。检查所用版本、镜像类型和资源挂载，再决定是否补依赖；不要随意在运行中的容器里安装一套东西后忘记记录，重建时这些改动可能丢失。
域名访问还要检查上传路径
完成初始化后，可以用已有反向代理提供 HTTPS，指向本机8080端口。小文件处理正常之后，再逐步测试接近自己日常规模的文件。
上传失败可能来自代理限制、应用限制、网络超时或磁盘空间。413这类响应与任务开始后失败不是同一阶段，按请求路径区分排查。不要只提高应用参数，却忽略代理仍然拒绝上传。
处理时间较长时，应看容器日志和资源占用。浏览器等待不代表任务没有开始，也不代表再次点击会更快。避免重复提交同一大文件，让几个任务一起争抢内存。
多人使用时约定任务规模与用途，不需要把工具页变成无范围的公共文档处理服务。上传内容、历史记录与日志按实际版本检查保留位置，不应假定关掉浏览器就清除了服务器上的材料。
三类处理结果，各自用不同方法验收
合并后的文件应核对总页数、页序与页面方向；压缩文件应核对画质、文字可读性和目标大小；OCR 文件则应检查可检索文本与识别准确程度。三个操作共用一个“文件可以下载”标准，会漏掉不同问题。
可以建立一份不含私人内容的固定样本包。每次升级后用相同输入和设置执行，记录输出差异。样本不必很大，包含横向页、小字号、图片与中文文本，已经能覆盖不少日常情况。
转换图片时看分辨率与页数，避免默认设置只导出第一页，或者输出的压缩包没有完整下载。批量文件也要清点数量，网页显示处理结束不等于本机已经保存所有结果。
对于有密码保护的文档，先确认自己有权进行相应操作，并按照工具支持的方式提供必要密码。不要把密码写进共享文件名或截图。解锁后的副本可能比原件更容易被读取，保存位置按实际用途安排。
服务器内存不足时，先缩小任务
任务开始后容器退出，查看 Docker 状态与日志，判断是否有内存相关终止或其他错误。先用少页样本复测，确认是资源问题还是输入本身无法处理。大文件拆成合理范围有助于验证，但拆分后仍要核对完整结果。
同时检查磁盘和临时空间。镜像、日志、上传和转换中间文件都会占用资源，系统盘接近满额时，处理失败未必会在页面给出直观提示。处理容量应由自己的样本和并发需求确定，不能从“支持 Docker”直接推断一台小 VPS 足够。
反复点击提交不会扩大服务器容量。任务状态不明确时先观察日志与进程，再决定取消或重试，避免同一份材料占用多份处理资源。
升级和清理分别操作
项目仓库与官方文档记录功能和安装变化。升级前备份配置、记录镜像版本，阅读需要的迁移说明。新版本跑起来后，重复合并、压缩与 OCR 样本测试，再处理正式文件。
小规模实例可以在暂停服务时归档持久化目录：
umask 077
docker compose stop stirling-pdf
tar -czf stirling-configs.tar.gz configs
docker compose start stirling-pdf
这个归档覆盖示例配置目录，不能自动代替源文件备份。日志与临时文件如何保留，按自己的使用范围和具体版本配置。清理前确定目录用途，不能为了释放空间删掉所有挂载目录。
恢复到私人测试入口后，检查账号、设置和样本任务。文档处理工具的验收应落在输出：完整、可读、符合用途，而不只是容器在运行。把这些习惯安排好，常见 PDF 工作就能留在一个熟悉入口完成。