docker-compose.yml 不必在根目录，但默认只读当前目录的该文件；可用 -f 指定任意路径，支持多文件叠加（后加载覆盖前一个）；build 与 image 并存时构建仍执行但镜像按 image 命名；network 需顶层声明且服务显式加入；env_file 变量总被 environment 覆盖。
docker-compose.yml 文件必须放在项目根目录吗
不是必须，但 docker-compose 默认只认当前工作目录下的 docker-compose.yml 或 docker-compose.yaml。如果文件在别处，得显式指定路径。
- 用
-f参数加载任意位置的文件：docker-compose -f /path/to/docker-compose.yml up - 多个文件叠加？可以多次用
-f，后加载的配置会覆盖/合并前一个（注意：service 级别是替换，environment 等字段是合并） - 常见踩坑：执行命令时 pwd 不对，报错
ERROR: .FileNotFoundError: docker-compose.yml not found—— 其实文件存在，只是没在当前目录
build 和 image 同时写在 service 里会发生什么
会冲突。如果同时声明 build 和 image，docker-compose build 仍会构建镜像，但构建完会按 image 字段重命名并打标签；而 docker-compose up 启动时优先使用 image 指定的名字拉取或运行，不一定用本地刚构建的镜像。
- 想确保用本地构建结果？删掉
image行，或让image值和build输出一致（如image: myapp:latest+build: .） - 想跳过构建直接拉远端镜像？只留
image，删掉build - CI/CD 场景下容易误配：本地测试用
build，上线却漏删build导致部署时意外触发构建
networks 配置不生效的典型原因
最常见的是 network 名字没对上，或者服务没显式加入网络 —— docker-compose 不会自动把所有 service 接入默认网络以外的自定义网络。
- 自定义 network 必须在顶层
networks:下声明，且每个 service 要通过networks:字段手动加入：networks: [mynetwork] - 不同 compose 文件间 network 隔离：用
external: true才能复用已存在的网络（比如其他项目创建的） - 容器启动后检查：
docker network inspect <network-name></network-name>，确认容器是否出现在Containers列表里 - 别名（
aliases）只在该 network 内有效，跨 network 的服务发现要靠 network 共享或 DNS 设置
env_file 和 environment 混用时变量怎么覆盖
顺序决定优先级：environment 字段里的值永远覆盖 env_file 里同名变量，无论 env_file 加载多早。
-
env_file适合放通用配置（如 DB_HOST、REDIS_PORT），environment适合放环境特例（如本地调试用DEBUG=true） - 文件内变量不支持 shell 展开（
HOME不会被替换成路径），也不解析$VAR引用，纯文本读取 - 想让 env_file 支持变量继承？得用
.env文件（顶级）+docker-compose.yml中引用${VAR}，但那是另一套机制，和env_file无关
复杂点在于：.env 文件、env_file、environment、命令行 -e 四层作用域，实际项目里建议只保留两层（比如 .env + environment），否则改个变量都不知道从哪冒出来的。
