docker compose restart不生效是正常现象，因其仅重启容器进程而不重建，端口等声明式配置需通过docker compose up -d --no-deps服务名重新加载并验证。
改了 ports 或其他配置后，用 docker compose restart 不生效——这是正常现象，因为 restart 只重启容器进程，不重新加载 ports、volumes、environment 等声明式配置。
为什么 docker compose restart 不应用新端口
Docker Compose 的 restart 命令本质是调用 docker restart ，它只触发容器内主进程的 SIGTERM → SIGKILL → 重启，完全绕过 Compose 的配置解析和容器重建流程。端口映射（ports）属于容器创建时绑定的网络参数，一旦容器启动完成就固定，无法热更新。
- 即使你改了
compose.yaml里的- "127.0.0.1:18080:80"，restart后仍走旧的8080:80绑定 -
docker compose ps显示的 PORTS 列仍是旧值，不是 bug，是预期行为 - 这个限制和 Docker 引擎本身有关，不是 Docker Desktop 特有
在 Docker Desktop 中真正重建单个服务的命令
Docker Desktop GUI 本身不提供“重载配置并重建”的按钮，必须通过 CLI 执行正确命令。核心是：**先停旧容器，再按新配置拉起新容器**，且避免波及其他服务。
- 确保你在项目根目录（
compose.yaml所在路径），或显式指定-f和-p - 运行
docker compose up -d --no-deps --remove-orphans -
--no-deps防止连带重启依赖服务（如db） -
--remove-orphans清理可能残留的旧容器（尤其当你改过服务名或配置结构） - 如果镜像有本地构建（
build:），加--build；若只改ports或environment，可省略
例如：改完 web 的端口后，执行 docker compose up -d --no-deps web 即可。
验证新配置是否生效的三步检查法
别只信命令输出，要确认宿主机、容器网络、实际监听三者一致：
- 查 Compose 解析出的最终配置：
docker compose config | grep -A 5 "web:"，确认ports字段已更新 - 查容器实际绑定：
docker compose port web 80，输出应为127.0.0.1:18080（不是旧的8080） - 查宿主机监听状态：
ss -tlnp | grep ':18080'（Linux）或netstat -anv | findstr :18080（Windows PowerShell），确认是dockerd进程在监听
如果第 2 步对不上，说明没成功重建——大概率是命令漏了 --no-deps 导致 Compose 用了缓存的旧容器，或者项目名（-p）不匹配导致读错文件。
最容易被忽略的是项目上下文一致性：Docker Desktop 左侧 Containers 标签页里显示的容器，可能属于另一个 -p 指定的项目，或来自不同目录下的 compose.yaml。每次操作前用 docker compose ls 确认当前活跃项目，比反复 restart 更省时间。
