docker容器化改造需围绕环境固化、服务封装、资源可控、交付可验四大目标展开，强调标准化解决“本地能跑、上线不稳”问题；依应用类型选择单体整体容器化、高频组件优先容器化或微服务化同步推进；精简基础镜像，分离不可变与可变内容，封装为标准可调用服务接口。
明确改造范围与策略
先判断你的应用类型，再选适配路径：
- 单体应用整体容器化：适合快速验证或遗留系统，不改代码，直接打包运行时+代码+配置，部署快但后期扩展难
- 高频组件优先容器化：比如AI模型服务、图片处理模块、OCR引擎等独立性强、资源消耗大的部分，先拆出来单独做镜像
- 微服务化+容器化同步推进：适用于新架构设计，按业务域拆分服务，每个服务独立构建、部署、扩缩容
精简基础镜像，控制体积与风险
别直接用ubuntu:latest或nvidia/cuda:full——它们体积大、漏洞多、启动慢。
- 优先选ubuntu:22.04或python:3.10-slim这类轻量发行版，删掉/usr/src、/var/lib/apt/lists等非运行必需目录
- GPU场景下，只装cuda-toolkit-12-1-runtime（非完整开发套件），手动指定libcudnn8=8.9.7.29-1+cuda12.1版本，避免自动升级引发兼容问题
- 生产环境推荐distroless或alpine镜像，移除shell和包管理器，安全加固且体积可压至25MB以内
分离不可变与可变内容
镜像要“一次构建，处处运行”，就得让里面的东西分清哪些该固化、哪些该外置：
- 固化进镜像的：运行时（Python/Java）、框架（PyTorch/TensorFlow）、依赖库（requirements.txt）、启动脚本、默认配置
- 挂载或注入的：模型权重（如/models目录）、用户上传文件、日志输出路径、数据库连接地址（通过环境变量传入）
- 避免硬编码路径，所有外部路径都通过ENV或--mount参数动态指定
封装成可调用的服务接口
命令行脚本能跑≠生产可用。容器化后必须提供标准访问方式：
- Web类服务（Gradio、FastAPI、Flask）：暴露PORT环境变量，默认监听0.0.0.0:7860或8000，加健康检查端点/health
- CLI类服务（如MinerU PDF解析）：支持HTTP POST接收PDF文件，返回JSON或Markdown，而非仅支持本地文件路径
- 统一日志输出到stdout/stderr，便于Docker日志采集；错误信息带上下文（如文件名、模型版本），方便排查
