生产环境docker核心要求是稳、清、快、动：①镜像须用多阶段构建+alpine/distroless基础镜像，体积压至200mb内并禁用latest标签；②健康检查需真实访问业务端点，配全timeout、retries、start-period且联动自动重启；③状态数据挂命名卷并匹配uid，配置走环境变量；④强制设置memory和cpus限制，i/o服务加blkio-weight。
直接看核心痛点，别被概念绕晕。
生产环境用 Docker，不是“跑起来就行”，而是“稳得住、查得清、扩得快、换得动”。
很多团队卡在从开发到上线的临界点，问题往往不出在技术多难，而在于几个关键环节被忽略。
镜像不能只图构建快，得管住体积和一致性
- 多阶段构建是标配，别再用
ubuntu:latest或python:slim里装一堆没用的包；推荐python:3.11-alpine或distroless基础镜像，构建后体积压到 200MB 以内才算过关 - 每次构建后用
dive myapp:latest看层分布，确认没混进.git、__pycache__、.env这类不该进镜像的东西 -
latest标签禁止上生产，CI 流水线必须校验镜像 tag 是语义化版本（如v2.3.1），且自动拒绝超 500MB 的镜像推送
容器启动不等于服务可用，健康检查得真能“看病”
-
depends_on只控制启动顺序，不保证依赖服务已就绪；必须配healthcheck，且命令要真实访问业务端点（比如curl -f http://db:5432/health或pg_isready -U appuser -d mydb） - 超时（
timeout）、重试（retries）、宽限期（start-period）三个参数要按服务冷启动时间调：Java 应用通常需start-period: 120s，Go 服务 30s 就够 - 健康检查失败后，配合
--restart unless-stopped才有意义；光有检查没重启策略，等于装了仪表盘却不看指针
数据和配置别靠“运气”，得有明确归属
- 所有状态数据（数据库文件、上传目录、日志归档）必须挂载命名卷（
named volume）或绑定宿主机路径，但要注意权限：非 root 容器用户 UID 必须和宿主机目录属主一致，否则写入失败 - 配置统一走环境变量，遵循 12-Factor 原则；用
.env.prod+env_file: .env.${ENV_MODE}分环境加载，别在代码里硬编码config.yaml路径 - 时区别默认 UTC：启动容器时加
-v /etc/localtime:/etc/localtime:ro，或者在 Dockerfile 里RUN apk add --no-cache tzdata && cp /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
资源限制不是可选项，是上线前必填项
- 内存限制必须设
--memory，否则 OOM Killer 会随机杀进程；建议值 = 峰值内存 × 1.3～1.5，预留缓冲 - CPU 限制推荐
--cpus=0.5起步，压测后再调；别只设--cpu-shares，它不防争抢，只管权重 - Redis、MySQL 这类 I/O 密集型服务，额外加
--blkio-weight控制磁盘优先级，避免拖慢其他服务
不复杂，但容易忽略。
