docker-compose exec 是进入已启动 Compose 服务容器终端的首选方式，需确保 docker-compose.yml 存在且服务已通过 up -d 启动；执行 docker-compose exec /bin/sh 或 /bin/bash（依镜像而定），自动匹配项目上下文，避免手动查容器ID出错。
docker-compose exec 是进入 Docker Desktop 中 Compose 服务容器终端的首选方式，不是 docker exec，也不是 docker-compose run —— 后者会新建容器，容易误操作导致状态错乱。
怎么用 docker-compose exec 进入指定服务容器
前提是项目目录下有 docker-compose.yml，且服务已通过 docker-compose up -d 启动成功。
- 先确认服务名：查看
docker-compose.yml中services:下一级的键名（如web、api、db），不是镜像名或容器名 - 执行命令：
docker-compose exec web /bin/sh（Linux/Alpine 镜像常用）或docker-compose exec api /bin/bash（Ubuntu/Debian 类） - 如果提示
command not found，说明容器里没装对应 shell，可退而求其次用/bin/sh或直接sh；部分极简镜像只提供sh - Windows PowerShell 或 CMD 中执行时，不要加
winpty—— Docker Desktop for Windows v4.10+ 已原生支持交互式终端，加了反而卡住
为什么 docker exec 容易出问题
它绕过 Compose 的服务抽象层，直接操作容器 ID，而 Compose 启动的容器名是自动生成的（如 myapp-web-1），每次重建都变；手动查 ID 再 exec 效率低、易选错容器。
- 查容器名要先跑
docker-compose ps，再复制名字，多一步就多一个出错点 - 如果服务用了
scale或重启过，docker ps里可能看到多个同名前缀的容器，docker exec选错一个就进错环境 -
docker-compose exec自动匹配当前 compose 项目上下文和服务定义，不依赖容器名稳定性
进不去？常见卡点和应对
现象：命令无响应、闪退、报错 No such container 或 rpc error: code = 2
- 服务根本没运行：执行
docker-compose ps，看对应服务状态是不是Up；如果是Exit，先docker-compose logs <service></service>查启动失败原因 - 容器启动后立刻退出：比如
db服务配置了错误的POSTGRES_PASSWORD，容器起不来，exec 就找不到目标 - Windows 路径映射冲突：若
volumes挂载了 Windows 路径（如C:\myapp:/app），某些 Alpine 镜像因 glibc 兼容性问题无法正常启 shell，换成ubuntu:22.04基础镜像或改用 WSL2 后端可缓解 - Mac 上 zsh 报
exec: "/bin/bash": stat /bin/bash: no such file or directory：不是权限问题，是镜像里真没 bash，换/bin/sh即可
进容器后想干点别的？别忽略这些细节
进去了不代表万事大吉。很多调试行为在 Compose 管理的容器里有隐含约束：
- 修改容器内文件（如
/etc/nginx/conf.d/default.conf）不会持久化——下次docker-compose up -d重建，又回原始镜像状态；要改配置，得改宿主机挂载的文件或重建镜像 - 安装软件（如
apt-get install curl）只在当前容器实例生效，不可复现，也不该作为长期方案 - 若服务用了
restart: unless-stopped，你 exec 进去后手动exit，容器不会停；但若在容器里执行reboot或init 6，会导致容器异常终止，Compose 可能自动拉起新实例，老状态丢失
