Ctrl+Shift+P执行“Dev Containers: Reopen in Container”是启动多容器环境的核心入口，它会读取.devcontainer/devcontainer.json、解析dockerComposeFile路径、按依赖顺序启动所有服务、挂载代码至指定service容器并自动转发forwardPorts端口。
VS Code 的快捷键本身不直接控制 Docker Compose，但配合 Docker 扩展和 Dev Containers 后，能大幅缩短多容器启停、日志查看、端口转发等高频操作的路径。关键不是记一堆快捷键，而是把「触发动作」和「背后执行的 Compose 行为」对齐。
Ctrl+Shift+P 里搜 Dev Containers: Reopen in Container 是启动多容器环境的核心入口
这个命令不是简单重启当前窗口，而是触发整套流程：读取 .devcontainer/devcontainer.json → 解析 dockerComposeFile 字段指向的 docker-compose.yml → 启动所有服务（包括 depends_on 依赖顺序）→ 挂载代码到 service 指定的容器 → 自动转发 forwardPorts 列表里的端口。
- 必须确保
devcontainer.json中dockerComposeFile路径正确，比如写成"../docker-compose.yml"却把文件放在同级目录，就会报Failed to resolve docker-compose.yml - 如果
service字段值和docker-compose.yml里某个 service 名不一致（大小写敏感），VS Code 会卡在“Starting dev container…”状态，且无明确错误提示 - 首次运行时，VS Code 会拉取镜像并构建（如有
build:），这个过程无法用快捷键中断，只能关掉弹窗或手动docker-compose down
Ctrl+Shift+P + Docker: Show Logs 查看指定容器日志，比 docker-compose logs -f 更聚焦
这个命令会弹出下拉菜单，列出当前所有运行中的容器（按 docker-compose.yml 定义的服务名显示），选中后直接在 VS Code 面板内打开只读日志流。它底层调用的是 docker logs -f <container_id>，而非 docker-compose logs，所以不会受 docker-compose.yml 中 logging 配置影响。
- 日志面板默认不自动滚动到底部，需要手动拖或按
End键；右键菜单里没有“自动滚动”开关 - 如果某服务刚崩溃退出，
Show Logs仍能查到最后输出，但不会实时刷新——因为容器已停止，这点和docker-compose logs -f行为不同 - 想看多个服务日志？只能挨个点开，VS Code 不支持日志合并视图；临时替代方案是终端里跑
docker-compose logs -f app db redis
调试微服务时，F5 启动的是容器内进程，不是本地 Node/Python 进程
当使用 Dev Containers + Compose 启动后，VS Code 的调试器连接目标是 app 容器内部的进程。这意味着 launch.json 的 program 路径是容器内的绝对路径（如 /workspace/src/index.js），不是你本地文件系统路径。
- 断点必须设在容器内可访问的文件上；如果
volumes挂载用了:cached或:delegated（macOS/Linux），修改本地代码会同步，但 Windows 上 WSL2 backend 有时有延迟 - 调试器无法跨容器附加——比如你在
app容器里 debug，不能直接 attach 到db容器的 PostgreSQL 进程；要调试数据库需单独配attach类型配置，且目标容器得开放调试端口 -
forwardPorts只做 TCP 端口映射，不处理 Unix socket 或 UDP；若微服务间用 socket 通信（如某些 Go 服务），需在docker-compose.yml里显式配置volumes挂载 socket 文件路径
快速清理残留：别只靠 Ctrl+Shift+P + Dev Containers: Close Remote Connection
这个命令只是断开 VS Code 和容器的连接，并不会停止或删除容器。实际开发中常遇到：改了 docker-compose.yml 重新 Reopen in Container，但旧容器还在后台跑着，导致端口冲突或数据错乱。
- 真正清理应执行
docker-compose down（在项目根目录终端），它会停止并移除容器、网络，但保留 volume 数据；加-v才删 volume - VS Code 终端里执行
docker-compose down后，再用快捷键 reopen，才能确保干净重启；否则可能复用旧容器状态 - 如果
docker-compose.yml里定义了restart: unless-stopped，down后它不会自动重启，这点和docker run --restart行为一致
最易被忽略的点是：VS Code 的 Dev Containers 和 Docker 扩展虽然共享 docker-compose.yml，但各自缓存行为不同。改完 compose 文件后，有时需手动 Ctrl+Shift+P → Developer: Reload Window，否则扩展可能读取旧的解析结果。
