docker-compose.yml中depends_on仅控制启动顺序而非服务就绪，需配合healthcheck与service_healthy或应用层重试；依赖应构建时安装；源码用volumes挂载但排除venv；环境变量需显式透传或容器内加载；gunicorn worker数应据内存限制调整；日志须输出到stdout/stderr。
docker-compose.yml 里 services 下的 depends_on 不等于“等它启动完”
它只控制容器启动顺序，不检查服务是否真正就绪。比如 depends_on 写了 db，但 postgres 容器可能刚跑起来、还在初始化，你的 Python 应用就去连，结果抛出 ConnectionRefusedError 或超时。
- 真正要等数据库就绪，得在应用侧加重试逻辑（比如用
tenacity库轮询psycopg2.connect）或用健康检查 +healthcheck配合condition: service_healthy -
depends_on的condition: service_started（默认值）只是看容器是否running，不是ready - Docker Compose v2.15+ 支持
service_healthy，但前提是目标服务定义了healthcheck，否则会报错
Python 应用镜像别用 pip install -r requirements.txt 在运行时装依赖
每次 docker-compose up 都重装，既慢又破坏镜像分层缓存。更糟的是，如果网络波动或 PyPI 暂不可用，构建直接失败。
- 把
requirements.txtCOPY 到镜像里，再 RUNpip install -r requirements.txt，确保依赖在构建阶段固化 - 开发时想快速改代码？用
volumes挂载源码目录，但别挂载venv或__pycache__，否则可能和容器内 Python 解释器冲突 - 避免在 Dockerfile 里写
RUN pip install flask gunicorn psycopg2-binary这种硬编码——版本不一致、难审计、无法复现
环境变量从 .env 文件漏进容器，但 Python 读不到
docker-compose.yml 支持 env_file，但那只是把变量注入容器环境；Python 默认不自动加载 .env 文件，os.getenv("DB_URL") 为空不是 Docker 的锅，是应用没处理。
- 要么在 Python 启动前用
env_file+environment显式透传关键变量，比如：environment: - DATABASE_URL=${DATABASE_URL} - 要么在 Python 里用
python-decouple或dotenv加载.env——但注意：这个.env是容器内的文件，得 COPY 进去，不能靠宿主机挂载（否则 dev/prod 环境混了） -
.env文件里的变量不会自动覆盖environment中已声明的值，后者优先级更高
gunicorn 和 Flask 的 workers 数设成 CPU 核数 × 2 是错的
这是 Web 服务器通用建议，但对容器化 Python 应用不适用。Kubernetes 或 Docker 的资源限制（mem_limit, cpus）是硬边界，而 gunicorn 的 worker 进程吃内存很猛，设多反而触发 OOM Kill。
立即学习“Python免费学习笔记（深入）”；
- 先用
docker stats观察单个实例实际内存占用，再按容器mem_limit反推合理 worker 数，通常 1–4 个足够 - 用
--preload参数让 gunicorn 预加载应用，避免每个 worker 单独 import，减少内存重复占用 - 别在
command里写死gunicorn --workers 4，改成环境变量驱动，比如command: gunicorn --workers ${WEB_CONCURRENCY:-2}，方便不同环境调整
最常被跳过的其实是日志——容器里 stdout/stderr 必须干净输出，别 redirect 到文件，否则 docker-compose logs 就抓不到；还有健康检查路径，别写成 /healthz 却在 Flask 里没注册路由，一查就失败。
