能直接运行，但必须满足三个硬性条件：docker-compose.yml在工作区根目录、docker cli可用、服务定义里没写死localhost通信；点“compose up”没反应需优先排查这三项，容器连不上多因监听地址非0.0.0.0或跨服务调用误用localhost而非服务名，dev container模式下须在devcontainer.json中显式指定dockercomposefile和service字段。
能直接运行，但必须满足三个硬性条件：docker-compose.yml 在工作区根目录、Docker CLI 可用、服务定义里没写死 localhost 通信。
点 “Compose Up” 没反应？先查这三件事
VS Code 不自己执行命令，它靠 Docker 扩展调用本地 docker compose up。没反应=调用失败，不是 UI 卡了。
-
docker compose version在 VS Code 集成终端里能跑通吗？不能→重装 Docker Desktop 或检查 PATH - 当前打开的文件夹根目录下真有
docker-compose.yml吗？不是docker-compose.yaml、不是compose.yml、也不是放在./infra/子目录里 - 右键 Docker 扩展侧边栏里的 compose 文件 → “Set as Active Compose File” 了吗？多个文件共存时必须手动指定
容器启动了但连不上服务？别急着改端口映射
90% 的“连不上”问题出在容器内监听地址或网络隔离上，和宿主机端口映射关系不大。
Docker Image Puller
下载
使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。
- 服务进程是否监听
0.0.0.0:端口？写127.0.0.1或localhost就只能本容器访问 - 跨容器调用（比如 web 连 db）必须用服务名（
mysql、redis），绝不能写localhost——容器里localhost指自己 - 默认 bridge 网络不支持服务名解析，
docker-compose.yml里得显式定义自定义网络：networks: [app-net]，所有服务都加networks: - app-net
Dev Container 模式下 compose 不生效？devcontainer.json 必须填对这两项
VS Code 在 “Open Folder in Container” 时完全忽略同目录的 docker-compose.yml，除非你明说用哪个服务。
-
"dockerComposeFile"字段必须存在，值是相对路径，比如"./docker-compose.dev.yml"，不能省略 -
"service"值必须和docker-compose.yml中services下的键名**完全一致**（大小写敏感），比如写的是services: api:，这里就得填"api"，填"API"或"backend"都会 fallback 到本地构建 - 如果服务用了
build:，Dockerfile 里WORKDIR和devcontainer.json中的"workspaceFolder"要对齐，否则挂载后代码目录为空
日志空白或断点不命中？进程和调试端口常被 silently 吃掉
VS Code 日志面板只抓 stdout/stderr，调试器只认 PID 1 是真实服务进程——这两点一错，现象就是静默失败。
- Node.js 项目避免
CMD ["npm", "run", "dev"]，某些 npm 版本 fork 后父进程退出；改用CMD ["sh", "-c", "exec npm run dev"] - Python 用 debugpy 时，
CMD ["python", "-m", "debugpy", "--listen", "0.0.0.0:5678", "app.py"]缺exec就会让 shell 占 PID 1，调试器连不上 - 服务启动命令里必须带
--inspect=0.0.0.0:9229（Node）或--listen 0.0.0.0:5678（Python），且不能被外层 shell 包裹后丢掉参数
最容易被忽略的其实是网络模型——你以为写了 ports: - "3000:3000" 就万事大吉，但 web 容器连不到 db，根本原因往往只是少了一行 networks: - app-net。调试器连不上也常因为 PID 1 不是服务本身，而你只盯着 launch.json 改配置。
