关键在于避开网络隔离、服务启动顺序、端口冲突三大断点：需自定义bridge网络实现dns解析，devcontainer.json的service与compose中services键严格对齐，mysql/redis配置healthcheck及密码，应用层仍需重试逻辑。
能直接做到，但关键不在“一键”，而在配置是否避开三个常见断点：网络隔离、服务启动顺序、主机端口冲突。
docker-compose.yml 必须显式声明自定义网络
默认 bridge 网络下，容器间只能靠 IP 通信，depends_on 不保证 MySQL 已 ready，只控制启动顺序。VSCode Dev Containers 启动时若 app 容器先连上未就绪的 MySQL，就会报 Connection refused。
- 在
docker-compose.yml顶层加networks块，例如：networks:<br> app-net:<br> driver: bridge<br> ipam:<br> config:<br> - subnet: 172.20.0.0/16
- 所有服务（
app、mysql、redis）都必须显式指定networks: [app-net] - 不要用
host或bridge这类内置网络名，它们不支持 DNS 自动解析服务别名
devcontainer.json 中 service 和 workspaceFolder 要对齐 compose 文件结构
VSCode 读取 devcontainer.json 后，会把 service 字段值当作目标容器名去匹配 docker-compose.yml 里的 services 键。如果填错，就找不到容器，报 Service 'xxx' not found。
-
service值必须和docker-compose.yml中某一个 service 的 key 完全一致（比如app） -
workspaceFolder必须是该 service 容器内真实存在的路径，且需配合volumes挂载项目源码，例如：volumes:<br> - ../src:/workspace/src
- 如果
app服务用了build:，确保Dockerfile中有WORKDIR /workspace，否则/workspace可能是空目录
MySQL 和 Redis 容器要暴露健康检查与可连接端口
VSCode 启动 Dev Container 时，不会等 MySQL 初始化完再让 app 连接——它只等容器进程 running。所以即使 depends_on 生效，mysql 容器里 mysqld 进程可能还在初始化表结构。
- 给
mysql加healthcheck，例如：healthcheck:<br> test: ["CMD", "mysqladmin", "ping", "-h", "localhost", "-u", "root", "-p$$MYSQL_ROOT_PASSWORD"]<br> timeout: 20s<br> retries: 10
- 给
redis加command: redis-server --requirepass $$REDIS_PASSWORD，避免默认无密码启动后被拒绝连接 - 所有服务的
ports字段仅用于从主机访问（如本地用 DBeaver 连 MySQL），容器间通信必须用服务名（mysql:3306、redis:6379）
最易被忽略的是：VSCode Dev Containers 启动时不会自动等待 healthcheck 成功，它只依赖 Docker 的 running 状态。所以你的应用代码里仍需实现连接重试逻辑，或者在 postCreateCommand 里用 wait-for-it.sh 主动等待 MySQL 就绪——这点文档很少提，但线上踩坑率极高。
