是，docker-compose.yml文件必须定义services，否则报错“Top level object must be an object, not a null”；每个service至少需指定image或build，二者不可同时省略，且服务间通信依赖默认bridge网络下的服务名DNS解析。
docker-compose.yml 文件必须定义 services，否则启动失败
不写 services 块的 docker-compose.yml 会直接报错：ERROR: Top level object in 'docker-compose.yml' must be an object, not a null.。Docker Compose 不接受空配置或仅含注释的文件。
每个 service 至少要指定 image 或 build ——前者拉取远程镜像（如 redis:7-alpine），后者指向本地 Dockerfile（如 build: ./api）。二者不能同时省略。
-
image更适合标准化服务（数据库、MQ、缓存） -
build更适合你自己的应用代码，且需确保路径下存在有效的Dockerfile - 若混用
build和image，docker-compose build会忽略image，但docker-compose up默认优先使用已构建镜像，不会自动重拉
容器间通信必须共用 network，不能靠 host 网络硬连
默认情况下，每个 docker-compose.yml 自动创建一个独立 bridge 网络，所有 services 都接入其中。这时服务名（如 db）就是 DNS 名，backend 可直接用 http://db:5432 连 PostgreSQL。
常见错误是：在 backend 中写死 localhost:5432，或在 db 里暴露 127.0.0.1:5432 ——这在容器内根本不通，因为 localhost 指向自己，不是宿主机也不是其他容器。
- 不要给服务加
network_mode: host，它会让容器共享宿主机网络，破坏隔离性，且跨服务 DNS 失效 - 不需要手动写
networks:块，除非你要自定义驱动（如driver: overlay）或连接外部网络 - 如果要用
depends_on控制启动顺序，注意它只控制容器创建顺序，不保证内部服务已就绪（比如 PostgreSQL 进程没启完）
docker-compose up -d 启动后，日志和状态检查不能只看终端输出
docker-compose up -d 返回成功，不代表所有容器都健康运行。比如 db 容器可能因环境变量缺失（如 POSTGRES_PASSWORD）立即退出，但 up 命令不阻塞也不报错。
真正确认状态得靠后续命令：
- 查运行中容器：
docker-compose ps，看 STATUS 列是否为Up，不是Exit 1或Restarting - 查某服务日志：
docker-compose logs -f db，加-f实时跟踪，避免只看首几行就误判 - 进容器调试：
docker-compose exec backend sh，然后手动curl -v http://db:5432测试连通性（PostgreSQL 不响应 HTTP，但能验证 DNS 和网络层）
volume 数据持久化容易漏掉命名卷声明
很多人写 volumes: - postgres_data:/var/lib/postgresql/data 却忘了在文件底部声明 volumes: 块，结果 Docker Compose 报错：ERROR: Volume postgres_data declared as external, but could not be found.
命名卷（named volume）和绑定挂载（bind mount）行为不同：
- 命名卷由 Docker 管理，路径抽象，适合数据库数据（如
postgres_data:必须出现在volumes:下） - 绑定挂载是宿主机路径映射（如
./config:/app/config），无需额外声明，但路径必须存在且权限正确 - 数据库类服务强烈建议用命名卷，避免因宿主机路径权限问题导致容器启动失败（尤其 macOS / Windows 上的 WSL2）
最常被跳过的一步，是改完 docker-compose.yml 后没执行 docker-compose down 就直接 up ——旧卷不会自动清理，残留数据可能干扰新配置。
