VSCode Docker扩展不容器化应用，仅管理镜像、容器等，依赖本地docker CLI；需确保CLI在PATH中可用，Dockerfile位于工作区根目录，compose修改后须先Down再Up。
docker CLI。如果你没配好底层环境，扩展点再多按钮也起不来。
确认 docker CLI 可被 VSCode 正确调用
这是最常卡住的第一步。VSCode Docker 扩展依赖系统 PATH 中能直接执行 docker 命令。
- 在 VSCode 终端里运行
which docker（macOS/Linux）或where docker（Windows），确保有输出 - 如果提示 command not found，说明 Docker Desktop 未安装，或已安装但未启用 CLI 工具（例如 macOS 上 Docker Desktop 默认勾选了 “Use the new Virtualization framework”，但 CLI 可能仍需手动开启）
- Windows 用户注意：WSL2 后端下，
docker必须从 WSL 发行版中可用，不能只靠 Windows PATH；建议在 VSCode 设置中指定docker.path指向 WSL 内路径（如/usr/bin/docker），或改用 WSL 窗口打开项目
右键生成 Dockerfile 时为什么没有 Node.js/Python 模板？
VSCode Docker 扩展的“Add Docker Files to Workspace”命令，模板来源取决于你当前打开的文件夹里有没有识别到对应运行时特征。
- 必须存在
package.json（Node.js）、requirements.txt或Pipfile（Python）、.csproj（.NET）等标志性文件，且文件位于工作区根目录或子目录中 - 如果项目是多语言混合，扩展默认只识别最顶层的主语言；可手动删掉自动生成的
Dockerfile，再用命令面板（Ctrl+Shift+P）运行Docker: Add Docker Files to Workspace，并显式选择平台（如node） - 生成的
Dockerfile默认使用多阶段构建，基础镜像为官方node:18-slim或python:3.11-slim，不自动适配你本地node -v或python --version输出
点击 “Build Image” 按钮后报错 “no such file or directory: Dockerfile”
这个错误不是 Docker 引擎的问题，而是 VSCode 扩展找不到上下文路径中的 Dockerfile。
- 确保你在资源管理器中已打开整个项目文件夹（而非单个文件），且
Dockerfile在该文件夹根目录下 - 扩展默认只扫描当前工作区根目录下的
Dockerfile；如果你把Dockerfile放在./docker/Dockerfile，它不会自动发现——需要右键该文件，再选 “Build Image from Dockerfile”，或手动在命令面板中运行Docker: Build Image并指定路径 - 构建上下文（build context）始终是
Dockerfile所在目录，不是 VSCode 当前打开的文件夹；若COPY ./src /app失败，大概率是相对路径写错了，不是扩展问题
FROM node:18-slim WORKDIR /app COPY package*.json ./ RUN npm ci --only=production COPY . . EXPOSE 3000 CMD ["npm", "start"]
docker-compose.yml 修改后，“Up” 容器没生效？
VSCode Docker 扩展的 “Compose Up” 功能只是调用 docker compose up，它不会自动 reload 或 hot-restart 运行中的服务。
- 修改
docker-compose.yml后，必须手动右键文件 → “Compose Down”，再 “Compose Up”，否则旧容器继续运行 - 如果服务用了 volume 挂载代码（如
./src:/app/src），改代码确实会实时生效，但前提是容器内进程支持热重载（比如 nodemon）；纯node index.js不会自动重启 - 扩展不解析
extends、profiles或环境变量插值（${VAR}）——这些全靠本地docker composeCLI 解析；确保你装的是 Docker Desktop 4.16+ 或独立docker-composev2.20+
