根本原因是VS Code GUI未继承系统PATH；macos需从终端启动code，windows需启用WSL2并配置终端，默认linux需加入docker组。
VS Code 安装 Docker 扩展后为什么 docker 命令仍不可用？
根本原因通常是 VS Code 没有继承系统 shell 的 PATH，尤其在 macOS 或 Linux 下通过包管理器（如 Homebrew）安装 Docker CLI 后，其路径未被 VS Code GUI 进程识别。
实操建议：
- macOS：在终端运行
code --install-extension ms-azuretools.vscode-docker后，**必须从终端启动 VS Code**（即执行code），而非点击 Dock 图标；否则扩展无法调用docker或docker-compose - Windows：确认已安装 Docker Desktop 且勾选 “Use the WSL 2 based engine”；检查 VS Code 设置中
terminal.integrated.defaultProfile.windows是否指向支持 Docker 的终端（如 PowerShell 或 git bash） - Linux：确保当前用户属于
docker用户组（sudo usermod -aG docker $USER），并重启会话（或登出重进）
如何让 VS Code 自动识别项目中的 Dockerfile 并启用容器调试？
VS Code 的 Docker 扩展不会自动启用调试，需手动配置 .devcontainer/devcontainer.json 或使用命令面板触发。
关键点：
- 若项目根目录存在
Dockerfile，按Ctrl+Shift+P（macOS 为Cmd+Shift+P），输入 “Dev Container: Open Folder in Container”，选择当前文件夹即可自动生成基础devcontainer.json -
devcontainer.json中必须指定"image"或"build"字段；仅写"dockerFile": "Dockerfile"不足以触发构建，需补全"build": { "dockerfile": "Dockerfile" } - 调试容器内进程（如 node.js、python）时，宿主机端口映射必须显式声明：
"forwardPorts": [3000, 5000]，否则断点无法命中
在容器中运行代码时，volume mount 权限错误（如 EACCES）怎么快速修复？
常见于 Linux/macOS 主机挂载源码到容器，容器内非 root 用户（如 node、python）无法写入挂载目录。
推荐做法：
- 避免在
Dockerfile中用USER node后直接挂载/workspace；改用WORKDIR /home/node/app+copy --chown=node:node . .预置文件 - 在
devcontainer.json中添加"runArgs": ["--user", "root"]临时绕过权限问题（开发阶段可接受） - 更稳妥的方式：在容器启动后执行
chown -R node:node /workspace，通过"postCreateCommand"实现
为什么修改代码后容器内服务没热更新？
不是 Docker 或 VS Code 的问题，而是镜像内缺少热重载机制 —— 容器只是静态运行你构建时的二进制或脚本。
解决方向取决于语言栈：
- node.js：确保
package.json中启用了nodemon，且devcontainer.json的"postAttachCommand"或启动脚本中执行的是npm run dev（而非npm start） - Python：用
uvicorn --reload替代uvicorn，并在devcontainer.json中设置"customizations": { "vscode": { "settings": { "python.defaultInterpreterPath": "/usr/local/bin/python" } } }确保插件识别正确解释器 - 通用原则：挂载源码的 volume 必须覆盖容器内原始代码路径（如
/workspace→/workspace），且容器内进程监听的是该路径下的文件变更
实际配置中最容易被忽略的，是 VS Code 终端环境变量与 GUI 启动方式的割裂，以及 devcontainer.json 中 build 和 runArgs 的协作关系 —— 单独改某一项常导致挂载失败或用户权限错乱。