Python Docker镜像需精简至120MB、安全可复现：用slim/alpine基础镜像、多阶段构建、pip--no-cache-dir、.dockerignore；编排须处理依赖顺序、配置外置、环境分层；开发与生产保持构建一致。
Python 应用的 Docker 镜像不是“能跑就行”，而是要小、快、安全、可复现；容器编排也不只是 docker-compose.yml 写几行，关键在服务依赖、配置分离和生命周期协同。
精简 Python 镜像：从 900MB 到 120MB
默认用 python:3.11 构建镜像常超 900MB，实际生产中多数 Python 应用只需解释器 + 依赖包 + 代码。优化核心是分层构建 + 多阶段 + 基础镜像降级：
- 优先选用
python:3.11-slim或python:3.11-alpine（注意 Alpine 的 glibc 兼容性，如用 pandas/scipy 建议 slim） - 多阶段构建：编译依赖（如 cryptography）用 builder 阶段，最终镜像只 COPY 编译产物和
requirements.txt安装结果 - 删除 pip 缓存、文档、测试文件：
RUN pip install --no-cache-dir -r requirements.txt && rm -rf /root/.cache/pip - 使用
.dockerignore排除__pycache__、.git、tests/、venv/等非运行时内容
安全与可复现：锁定依赖与最小权限
不锁版本的 requirements.txt 会导致不同时间构建出行为不一致的镜像；以 root 运行容器则放大漏洞风险：
- 用
pip-compile（来自 pip-tools）生成带哈希的requirements.txt，确保每次安装完全一致 - 添加非 root 用户：
RUN adduser -u 1001 -U -m appuser && usermod -L root，再USER appuser - 避免
pip install在容器内执行，所有依赖必须在构建阶段完成，运行时只启动应用 - 扫描镜像漏洞：
docker scan your-python-app或集成 Trivy 进 CI 流程
docker-compose 编排：不只是“一键启多个容器”
真实 Python 项目常含 Web 服务、异步任务（Celery）、缓存（Redis）、数据库（PostgreSQL），它们需按顺序就绪、共享配置、隔离网络：
立即学习“Python免费学习笔记（深入）”；
- 用
depends_on+ 自定义健康检查（如healthcheck检查 PostgreSQL 是否响应）控制启动依赖 - 配置外置化：通过
env_file加载.env，或挂载config/目录，避免敏感信息硬编码 - 为不同环境拆分 compose 文件：
docker-compose.yml（基础服务）+docker-compose.prod.yml（生产覆盖，如资源限制、日志驱动） - Celery worker 和 beat 应作为独立 service，共享同一镜像但启动不同命令，通过
command:区分
进阶实践：本地开发与生产的一致性
开发时用 volume 挂载代码实现热重载，上线却换成了 COPY —— 这种差异正是 bug 温床。解决思路是统一构建逻辑，差异化仅在运行时：
- 构建镜像始终用
Dockerfile，开发环境通过docker-compose.override.yml添加 volume 和command: python -m debugpy --listen 0.0.0.0:5678 --wait-for-client app.py - 使用
build.args控制构建参数，例如--build-arg ENV=dev决定是否安装 dev-dependencies - 镜像内不写死 host 地址（如
redis://localhost:6379），全部通过环境变量注入，由 compose 的environment或env_file统一管理 - 记录镜像元数据：在构建时写入 Git commit、构建时间、Python 版本到
/app/version.json，便于追踪和问题定位
镜像优化和编排不是一次性任务，而是随项目演进持续调整的过程。关键是把构建逻辑收口、把配置抽离、把依赖锁死——剩下的就是让 Docker 做它最擅长的事：可靠地运行业务代码。
