Docker Compose服务间网络通信失败主因是未正确使用depends_on和service名：容器内必须用服务名（如db）而非localhost访问数据库，depends_on仅控制启动顺序，需配合健康检查或重试逻辑确保数据库就绪。
docker-compose.yml 里 services 怎么写才不连不上数据库
服务间网络通信失败，90% 是因为没写 depends_on 或没用对服务名当主机名。Docker Compose 自动创建默认网络，容器内访问其他服务必须用 service name（不是 localhost），比如 Python 代码里连 MySQL 要写 mysql://root:dev123@db:3306/myapp，其中 db 是你在 docker-compose.yml 里定义的 service 名。
-
depends_on只控制启动顺序，不等数据库 ready 就退出；加健康检查才能真正等待就绪 - Python 服务启动时若数据库还没响应，会报
ConnectionRefusedError或超时；建议在代码里加重试逻辑，或用wait-for-it.sh脚本 - MySQL 容器暴露端口是
3306，但 Python 连接时不能用宿主机127.0.0.1:3306，必须用服务名db:3306
Python 微服务镜像怎么构建才支持热更新
本地改代码、容器里立刻生效，关键不是靠 docker run -v，而是靠 docker-compose.yml 里的 volumes 挂载 + 启动命令适配。Flask 默认不自动 reload，得显式加 --reload 参数，否则改了代码也得重启容器。
- 在
docker-compose.yml的 Python 服务里写：volumes: ["./src:/app/src"]，确保路径映射正确 -
command字段要覆盖默认 CMD，比如写成command: python -m flask run --host=0.0.0.0:5000 --port=5000 --reload - 别在 Dockerfile 里用
COPY . .把整个项目 COPY 进镜像——那样挂载卷就无效了；只 COPY 依赖和基础文件，源码靠 volume 动态挂载 -
.dockerignore必须包含__pycache__、venv、.git，否则 build 会变慢，且可能把本地环境污染进镜像
多个 Python 服务共用一个 requirements.txt 会出什么问题
不同微服务依赖版本冲突，比如订单服务要 requests==2.28.0，用户服务要 requests==2.31.0，全塞进一个 requirements.txt 会导致某个服务启动失败或行为异常。Docker Compose 不强制隔离 pip 环境，每个服务应有独立依赖管理。
python-script-generator
下载
快速生成专业的 Python 脚本和应用代码。一键创建完整项目结构，支持CLI、API、爬虫、Bot、Django等多种项目类型，包含完整的项目结构、配置文件、依赖管理、测试、README和文档。
- 每个服务目录下放单独的
requirements.txt，Dockerfile 里用COPY ./order/requirements.txt /app/再RUN pip install - 避免在顶层目录放通用
requirements.txt，更不要让所有服务build: .共用同一个 Dockerfile - 如果要用 Poetry 或 Pipenv，确保
pyproject.toml和poetry.lock在对应服务子目录下，且 Dockerfile 中工作目录设对 - CI 构建时若并行 build 多个服务，注意 pip 缓存可能混用；加
--no-cache-dir或用构建参数区分缓存键
docker compose up 启动后日志刷屏，怎么快速定位哪个服务挂了
默认 docker compose up 是前台运行、所有服务日志混在一起，一旦某个服务崩溃，容易错过关键错误行。真正高效的做法是分服务查日志 + 设置日志驱动收敛输出。
立即学习“Python免费学习笔记（深入）”；
- 启动时加
-d后台运行，再用docker compose logs -f api单独盯一个服务 - 在
docker-compose.yml的 service 下加logging:配置，比如限制大小：driver: "json-file"+options: {"max-size": "10m", "max-file": "3"} - 服务崩溃后，
docker compose ps一眼看出状态是Exit 1还是Restarting；docker compose logs --tail 50 api查最后 50 行 - 别依赖
restart: on-failure掩盖问题——它会让容器反复启停，掩盖真实异常；开发阶段建议设restart: "no"，手动排查
docker-compose.yml，先 docker compose config 验证 YAML 结构，再 docker compose down && docker compose up -d，比盲目重启强得多。 
