企业级Docker Compose落地需保障生产环境的稳定性、可观测性、可恢复性与可审计性：资源须硬限制（memory/cpus），配置健康检查（真实探针+合理超时重试），敏感信息分离管理（.env+Vault/secrets），网络与存储显式声明具名资源，内部通信走自定义网络。
企业级落地不是把 docker-compose.yml 从开发机拷过去就能跑通，而是让多服务在真实生产环境中稳定、可观察、可恢复、可审计地长期运行。关键不在“怎么写”，而在“为什么这么写”。
资源必须硬限制，不能靠经验估算
默认不设限的容器，在生产环境等于埋雷。一个内存泄漏的服务可能拖垮整台宿主机，OOM killer 杀错关键进程是常态。
- 每个
service下必须显式配置deploy.resources.limits，至少包含memory和cpus - 内存建议按压测峰值上浮 20%～30%，避免频繁触发 swap 或 OOM；CPU 限制宜保守（如
'0.5'），防止突发争抢影响其他服务 - 搭配
oom_kill_disable: false（默认）+ 合理 limit，能让内核在资源超限时精准 kill 掉越界容器，而非随机扫荡
健康检查不是可选项，而是服务可用性判定依据
depends_on 只控制启动顺序，不校验服务是否真正就绪。数据库容器进程起来了，但初始化脚本还没跑完，上游服务连接就会失败。
- 为所有关键服务（DB、缓存、API 网关等）添加
healthcheck，用真实业务探针（如curl -f http://localhost/health或pg_isready -U user -d db） - 设置合理超时（
timeout）、重试间隔（interval）和失败阈值（retries），避免过早判定失败或迟迟不发现异常 - 配合
restart_policy.condition: on-failure或on-unhealthy（v3.8+），实现故障自动恢复
配置与镜像分离，敏感信息严禁硬编码
密码、密钥、Token 写死在 docker-compose.yml 或 Dockerfile 中，等于把生产凭证明文提交到代码仓库。
- 统一使用
.env文件管理非敏感变量（如APP_ENV=prod），通过env_file或environment字段注入 - 敏感配置走 Docker secrets（Swarm 模式）或外部 Vault + runtime 注入，绝不在 Compose 文件中出现明文凭据
- 生产环境禁用
volumes挂载本地源码目录（如./src:/app），防止热更新机制引入不一致状态
网络与数据持久化需显式声明，拒绝默认隐式行为
Compose 默认创建的匿名桥接网络和卷，生命周期绑定于 docker-compose down，重启即丢数据，不符合生产持久性要求。
- 定义具名网络（
networks:下声明），并为每个服务指定networks: [mynetwork]，确保跨部署一致性 - 数据库等有状态服务必须使用具名卷（
volumes:下声明），禁止用./data这类相对路径绑定宿主机目录（权限、迁移、备份均不可控） - 对外暴露端口仅保留必要项（如 Nginx 的 80/443），内部服务间通信一律走自定义网络 + 服务名，不映射到宿主机端口
