直接 docker compose restart 不会加载新配置，必须用 docker compose up -d 重建容器；先运行 docker compose config 验证配置是否正确解析，注意 Windows 下换行符、路径格式及 Docker Desktop 资源限制。
改了 docker-compose.yml 里的 ports、environment 或 volumes，直接 docker compose restart 是没用的——容器不会读新配置，只会原地重启。
docker compose up -d 才是真正生效的操作
这是唯一能加载新配置并重建容器的标准方式。它会对比当前运行容器和 docker-compose.yml 的差异，只重建有变更的服务，保留未改动的服务状态。
-
docker compose up -d自动检测配置变化，销毁旧容器、拉取（如有必要）、启动新容器 - 如果只改了某个服务（比如
web），它默认只重建那个服务，不碰db或cache - 加
--no-deps可避免连带启动依赖服务，适合单点调试：docker compose up -d --no-deps web - 别用
restart，它连配置文件都不重读，纯粹发个SIGTERM再start
先用 config 确认你改的配置真被读进去了
很多人卡在“明明改了却没生效”，其实是编辑了错的文件、或在错的目录下执行命令。用 config 能看到 Compose 解析后的最终模型，是最可靠的验证手段。
- 运行
docker compose config，输出应包含你刚改的ports值（如"127.0.0.1:18080:80"） - 加
--quiet可快速检查是否语法合法：docker compose config --quiet，静默即通过 - 如果报错
yaml: line X: did not find expected key，大概率是缩进用了 tab 或冒号后少空格 - 注意项目名一致性：不同
-p参数会隔离出完全独立的容器组，docker compose -p myapp config和默认项目名查的不是同一套
Windows 下特别注意路径和换行符
Docker Desktop 在 Windows 上跑 Linux 容器，但 docker-compose.yml 是由宿主机上的 Compose CLI 解析的。换行符、路径分隔符、权限声明稍有不慎就会让挂载失败或配置静默忽略。
- 确保文件保存为
LF（Unix）换行，不是CRLF；VS Code 默认可能用 CRLF，需手动切换 - Windows 路径写进
volumes时，用正斜杠：./data:/app/data，别用.\data或C:\path - 如果用了
build:+Dockerfile，确认context路径是相对docker-compose.yml所在目录的，不是相对于 PowerShell 当前位置 - 挂载宿主机目录时，Docker Desktop 会弹窗请求访问权限（如
C:\Users），拒绝后该卷就为空，但不会报错
最常被忽略的一点：Docker Desktop 的资源限制（内存/CPU）默认偏低，改完配置后容器启动失败，日志里可能只有 exited with code 137——那不是配置问题，是 OOM Kill。先去 Docker Desktop 设置里调高 Memory（建议 ≥ 4GB）。
