VSCode 连不上 docker-compose 容器需检查 devcontainer.json 的 service 字段必须与 docker-compose.yml 中 services 下一级键名完全一致；确保容器有前台进程、跨容器用服务名而非 localhost、修改 compose 后需重建容器。
VSCode 连不上 docker-compose 启动的容器？先检查 devcontainer.json 的 service 字段
VSCode 的 Dev Containers 扩展不认 docker-compose.yml 里的服务名别名，它只认 services 下一级的键名。比如你的 compose 文件里写的是：
services:
app:
build: .
db:
image: postgres:15
那 devcontainer.json 里必须写 "service": "app"，不能写 "service": "backend" 或其他别名——哪怕你在 docker-compose.yml 里加了 container_name 也没用。
- 确保
service值和docker-compose.yml中services下的**第一级键名完全一致**（区分大小写） - 如果 compose 文件用了
extends或profiles，Dev Containers 默认不加载它们；得把目标服务的配置“展开”到主文件里再引用 -
docker-compose.yml必须放在工作区根目录，或通过dockerComposeFile显式指定路径，否则 VSCode 找不到
容器启动后 VSCode 提示 “The container is not running”？重点看 command 和 entrypoint
Dev Containers 要求目标容器里有持续运行的前台进程，否则它会认为容器“没起来”。常见坑是：Dockerfile 里用了 CMD ["npm", "run", "dev"]，但 npm run dev 在某些环境下会 fork 出子进程后父进程退出，VSCode 就判定容器已停止。
- 优先改用
command字段覆盖默认命令，例如："command": "bash -c 'npm install && npm run dev'" - 避免在
docker-compose.yml的command或entrypoint中使用sh -c包裹后不加exec，否则 PID 1 不是真正进程，容器易被误判为退出 - 调试时可在
devcontainer.json加"waitFor": "tcp://localhost:3000"，但前提是容器内服务真在监听该端口且未绑定127.0.0.1（得绑0.0.0.0）
多个容器间网络不通？别依赖 localhost，用 compose 的服务名当 host
VSCode 开发容器本身是独立容器，不是宿主机进程。你在代码里写 http://localhost:5432 访问数据库，实际连的是开发容器自己的 127.0.0.1，不是 compose 网络里的 db 容器。
- 所有跨容器调用必须用
docker-compose.yml里定义的服务名作 host，例如postgres://db:5432/mydb - 确认
devcontainer.json中customizations.vscode.settings没有意外覆盖terminal.integrated.env.linux导致环境变量丢失（比如PGHOST被设成localhost） - 如果要用
docker exec进容器调试，记得加--network参数指定 compose 网络，否则默认走 bridge，可能跨不了网
改了 docker-compose.yml 但重启 Dev Container 没生效？VSCode 缓存的是构建上下文，不是文件本身
VSCode Dev Containers 启动时会把当前工作区打包传进容器，并基于 docker-compose.yml 构建镜像。但如果你只改了 compose 文件里的 volumes 或 environment，而没改 build.context 对应的 Dockerfile 或源码，VSCode 可能复用旧镜像——因为镜像 ID 没变。
- 每次修改
docker-compose.yml中影响容器行为的字段（如environment,volumes,ports），都建议手动执行Remote-Containers: Rebuild Container - 如果用了
build.args，确保Dockerfile里用了ARG接收，否则参数白传 - 遇到诡异问题，直接删掉
.devcontainer/.dockercompose.build目录（如果有）和本地镜像（docker images | grep devcontainer），再重试
多容器开发里最麻烦的从来不是配置写法，而是哪个地方悄悄用了 localhost、哪个 service 名拼错了、哪次没 rebuild 就以为改完了——这些点不盯住，花再久配也白搭。
