直接用 docker-compose up 启动需确保 docker-compose.yml 存在且语法正确、Docker Desktop 服务就绪；文件须位于当前目录，不自动向上查找；依赖服务仅按顺序启动，不等待就绪，需配合 healthcheck 或外部工具验证可用性。
直接用 docker-compose up 就能启动，但必须确保 docker-compose.yml 文件存在、语法正确，且 Docker Desktop 后台服务已就绪。
docker-compose.yml 文件必须放在当前工作目录下
执行 docker-compose up 时，Docker Desktop 默认只读取当前目录下的 docker-compose.yml（或 docker-compose.yaml）。它不会自动向上查找父目录，也不会识别重命名的文件。
- 错误做法：
cd /path/to/project/src然后运行命令——如果docker-compose.yml在/path/to/project，会报错ERROR: No such file or directory: docker-compose.yml - 正确做法：先
cd /path/to/project，再运行docker-compose up - 临时指定路径可用
-f参数：docker-compose -f ./ops/docker-compose.prod.yml up
依赖容器启动失败会导致整个 docker-compose up 中断
比如 app 服务声明了 depends_on: [db]，但 db 容器因端口被占、镜像拉取失败或初始化脚本出错而退出，app 就不会启动，且命令卡住或直接退出，不会自动重试。
-
depends_on只控制启动顺序，不等待依赖服务“就绪”（例如 PostgreSQL 启动监听并接受连接） - 真实健康检查需配合
healthcheck+restart: on-failure或外部工具（如wait-for-it.sh） - 常见现象：
docker ps显示db是Restarting状态，app根本没出现——先docker logs db查错
Windows/macOS 上 WSL2 或 Rosetta 配置影响镜像兼容性
如果你在 Apple Silicon Mac 上用 postgres:15-alpine 没问题，但换成 mysql:8.0（x86_64 镜像）就报 exec user process caused: exec format error，说明架构不匹配。
- M系列芯片默认可运行 arm64 镜像；x86_64 镜像需启用 Rosetta（Docker Desktop 设置 → Features →
Use Rosetta for x86/amd64 emulation） - Windows 用户若用 WSL2，务必确认
wsl --list --verbose中docker-desktop的 VERSION 是 2，否则docker-compose可能静默失败 - 避免混用架构：统一用
alpine后缀镜像（如node:18-alpine、nginx:alpine），减少兼容问题
第一次启动后修改配置，必须用 --force-recreate 或 --build
改完 docker-compose.yml 里的环境变量、端口映射或 build.context，直接 docker-compose up 很可能复用旧容器，新配置不生效。
-
docker-compose up --force-recreate：强制重建容器（不重建镜像） -
docker-compose up --build：当服务用了build:字段时，重新构建镜像并启动 - 更彻底的做法：
docker-compose down && docker-compose up --build，尤其涉及 volume 数据或网络变更时
最常被忽略的是健康检查与依赖就绪之间的 gap：Docker Desktop 能保证容器“启动”，但不能保证服务“可用”。数据库连不上、Redis 认证失败、Nginx 配置语法错误……这些都会让 compose 项目看似启动成功，实则业务不可用。动手前先 docker-compose ps 看状态，再 docker-compose logs -f 追日志，比反复重启快得多。
