vscode不装入容器，而是通过remote-containers插件连接容器，代码、命令、调试均在容器内运行，ui在宿主机；因容器无gui支持，官方不支持桌面版装入镜像。
VSCode 本身不“安装在 Docker 容器里”，而是通过 Remote - Containers 插件连接到容器——你编辑的代码、运行的命令、调试的进程，全在容器内；VSCode 界面和 UI 还是在宿主机上跑。搞反这个主次关系，后续配置十有八九会卡在 Reopen in Container 不生效或终端打不开。
为什么不能直接把 VSCode 桌面版装进 Docker 镜像？
Docker 容器默认无图形界面、无 X11/Wayland 服务、无用户会话管理，而 VSCode 桌面版是 GUI 应用，依赖宿主机显示系统。强行打包进去不仅体积大、启动失败率高，还会绕过 Remote - Containers 的所有设计优势（如文件系统挂载、端口自动转发、扩展按需注入）。官方明确不支持这种用法。
- 你会看到
cannot open display或failed to load gdk backend类错误 -
code --install-extension在容器内执行无效：插件必须由宿主机 VSCode 安装并同步到容器 - 调试器、Git 集成、终端历史等核心功能全部降级或不可用
devcontainer.json 中 "image" 和 "build" 怎么选？
二者互斥，选错会导致构建失败或环境缺失。简单说："image" 是复用现成镜像（快但定制弱），"build" 是从 Dockerfile 构建（灵活但首次耗时）。
- 用
"image": "mcr.microsoft.com/vscode/devcontainers/python:3.11"：适合快速启动 Python 项目，但无法改 pip 源、加 system-level 依赖（如libpq-dev） - 用
"build": { "dockerfile": "Dockerfile" }：必须确保项目根目录下有Dockerfile，且其中包含USER vscode（否则 VSCode 无法以非 root 用户写入文件） - 混合用法（
"image"+"features"）更推荐：比如"image": "mcr.microsoft.com/vscode/devcontainers/base:ubuntu"，再通过"features"加装 Node.js、Python、Docker CLI 等，既轻量又可控
容器内终端打不开或提示 Permission denied？
根本原因通常是用户权限或 shell 路径配置错误，不是 Docker 权限问题。
- 检查
devcontainer.json是否设置了"settings": { "terminal.integrated.shell.linux": "/bin/bash" }—— 如果基础镜像用的是alpine，得改成/bin/sh - 确认
Dockerfile最后一行是USER vscode，而不是USER root；否则 VSCode 会拒绝挂载工作区 - 如果用了
docker-compose.yml作为后端，确保services.devcontainer.volumes包含${PWD}:/workspace:cached，否则文件系统不可写
如何让容器真正“隔离”而不偷偷读写宿主机？
隔离不是靠 Docker 自动完成的，关键在挂载策略和网络配置。默认行为其实很危险。
- 避免使用
volume或bind mount把整个家目录（/home/xxx）挂进容器——这等于把 SSH 密钥、Git 凭据全暴露给容器 - 只挂载项目根目录：
"mounts": ["source=${localWorkspaceFolder},target=/workspace,type=bind,consistency=cached"] - 禁用容器访问宿主机 Docker socket：
"runArgs": ["--network=host"]是反模式；如需构建镜像，用"features": { "docker-in-docker": "latest" }更安全 - 检查
forwardPorts是否只列了业务端口（如8000、3000），别把22、6379这类敏感端口也转发出去
最常被忽略的一点：容器退出后，docker ps -a 里残留的 vscode-xxx 容器不会自动清理。它们占内存、占磁盘、还可能让下次 Reopen in Container 复用旧状态——手动 docker rm -f $(docker ps -aq --filter "name=vscode") 才算真正“干净”。
