PDF 转换后端,我为什么选 Docker 而不是直接装环境

Docker没法让故障消失，它只是让部署和回滚更可控

小程序页面能展示出来以后，我很快碰到了一个现实问题：PDF转Word、Word转PDF、合并拆分，到底在哪里执行？

图片水印、颜色取色这类轻量操作，可以尽量留在手机本地。可Office转换涉及LibreOffice，PDF转Word也需要专门的解析库。把所有能力硬塞进小程序端，并不现实。

所以我给项目加了一套后端服务。

这套后端跑在腾讯云轻量应用服务器上，Docker也不是我手动敲命令装的，是用1Panel服务器面板自带的容器功能管理的。对不熟悉命令行的人来说，有个可视化面板点几下就能创建容器，门槛低很多。

用户在小程序里选择文件，通过HTTPS访问接口。服务器上装了1Panel面板，OpenResty接收请求后，反向代理到本机的Docker容器，容器里运行着FastAPI和转换工具。

链路可以简化成：

对外只开放反向代理入口，应用端口不直接暴露到公网。

我选 Docker，看中的就是环境可控。

这里说的Docker，就是1Panel面板里那个“容器”功能，不是什么高深的黑科技。1Panel装好后Docker环境默认就带了，创建容器、看日志、重启都能在网页上操作，不用记命令。

PDF和Office转换不只是一个Python文件。它依赖系统字体、LibreOffice、Python包和临时目录。直接在服务器系统里安装，短期也能跑，但以后升级或迁移，很容易遇到版本差异。

放进容器后，应用和依赖一起管理。需要回滚时，可以切回旧镜像；要迁移服务器时，也不用重新猜当初装过哪些组件。

对个人项目来说，这套做法比硬套微服务架构实用得多。

这个域名没有面向用户的Web首页，只给小程序提供接口。但“没有前端”不代表别人访问不到。

只要地址泄露，扫描器、爬虫和恶意请求照样能来。

我没给整个站点加网页密码，因为那样连小程序请求也会被拦住。更合适的做法是缩小暴露面：

这类服务最怕两件事：大文件拖垮内存，临时文件堆满磁盘。所以我给后端设了几条硬限制：

这些数字不是越大越好。个人服务器资源有限，明确边界反而能保证大多数正常任务可用。

升级后端时，我不会把新文件一覆盖就完事。

我的操作顺序是：备份旧版本，核对依赖变化，再用健康检查和真实文件验证。健康接口返回正常，只说明进程还活着；PDF转Word、合并拆分和图片转换仍要各跑一遍。

下一篇讲一次很典型的排障：后端明明正常，用户却一直看到“服务器响应异常”。最后的问题不在代码，而在WAF白名单。

我是 IT李工，17年IT运维出身，正在从0到1造一个PDF工具箱小程序。

既然看到这里了，如果觉得有用，随手点个赞、在看、转发三连吧。

THANKS FOR READING