远程容器连不上 docker daemon 的根本原因是 vscode 直连远端 docker socket，需确保用户属 docker 组、daemon 正常运行且监听正确（unix socket 或 tcp），并注意跨平台挂载路径、containeruser 权限及扩展兼容性。
远程容器连不上？先确认 SSH 和 Docker daemon 是否真正可达
VSCode 的 Remote-Containers 扩展不走 SSH 隧道，而是直连目标机器的 Docker daemon。很多人配完 SSH 能登录，就以为“远程开发”通了，结果 devcontainer.json 一拉就报 Cannot connect to the Docker daemon——本质是本地 VSCode（或 Remote-SSH 启动的 VSCode Server）根本没权限、也没路径访问远端 /var/run/docker.sock。
实操建议：
- 在远程机器上执行
sudo docker ps，确认 daemon 正常运行且当前用户在docker用户组里（否则必须加sudo，而 VSCode 不支持 sudo 连接 socket） - 如果用非 root 用户，务必运行
sudo usermod -aG docker $USER并重新登录 shell（仅newgrp docker不生效） - 检查远程 Docker 是否监听 TCP（默认只监听 Unix socket）。若需跨网络访问（如从 Windows 主机连 Linux 服务器），要改
/etc/docker/daemon.json加"hosts": ["unix:///var/run/docker.sock", "tcp://0.0.0.0:2375"]，并注意防火墙放行 2375 端口（⚠️不加密，生产环境慎用）
devcontainer.json 中的 remoteUser 和 containerUser 到底谁起作用
这两个字段常被混淆。简单说：remoteUser 控制 VSCode 连入容器后默认用哪个用户启动 shell；containerUser 决定容器内进程（包括 VSCode Server）以谁的身份运行——它才是真正影响文件权限、~/.vscode-server 归属、以及能否写入 /workspace 的关键。
常见错误现象：容器启动成功，但打开终端报 Permission denied，或扩展安装失败提示 “cannot write to /home/vscode/.vscode-server”。
实操建议：
- 优先设
"containerUser": "vscode"（前提是你的Dockerfile创建了该用户并配置了 home 目录），避免 root 用户写入导致本地挂载卷权限混乱 -
remoteUser只在你手动打开终端时生效，不影响 VSCode 自身行为；它默认继承containerUser，一般不用单独设 - 如果镜像没预装用户（如官方
python:3.11），必须在Dockerfile里显式创建用户，并用USER vscode切换，否则containerUser设置无效
挂载本地目录失败？警惕路径格式和符号链接处理差异
Windows 或 macOS 主机通过 VSCode Remote-Containers 挂载本地项目到容器时，容易出现 ENOENT 或空目录。问题往往不在配置本身，而在路径解析逻辑：VSCode 在宿主机上把 ./src 解析成绝对路径后传给远程 Docker，但远程机器上该路径根本不存在。
使用场景：你在 Mac 上编辑 /Users/me/project，想让容器内看到 /workspace 对应这个目录——但远程服务器根本没有 /Users/me/project 这个路径。
实操建议：
- 不要依赖相对路径。在
devcontainer.json中用"mounts"显式声明，例如："source": "/Users/me/project", "target": "/workspace", "type": "bind" - 如果远程机器无法直接访问本地磁盘（比如你连的是云服务器），必须先把代码同步过去（如
rsync或git clone），再用"workspaceFolder"指向远程路径，而非挂载 - 符号链接（symlink）在挂载后可能失效，尤其是跨文件系统（如 macOS APFS → Linux ext4）。测试方法：进容器执行
ls -l /workspace，看链接是否指向正确位置
扩展在容器里不生效？别忘了 extensions 字段只管安装，不管启用
很多人在 devcontainer.json 里写了 "extensions": ["ms-python.python"]，重启容器后 Python 扩展图标还在灰着，甚至没有语法高亮——因为 VSCode 默认不会在远程容器中自动启用这些扩展，除非它们明确声明支持“workspace extension”模式。
性能影响：强制启用不兼容的扩展可能导致容器内 CPU 占用飙升，或 VSCode 主界面卡顿。
实操建议：
- 只添加经过验证的远程友好扩展，查法：打开扩展详情页，看 “Supports Remote Development” 是否打勾；或者搜索时加关键词
remote，如remote - python - 某些扩展（如
esbenp.prettier-vscode）需额外配置"settings"指定 formatter 路径，否则找不到 Prettier 二进制文件 - 如果扩展仍不工作，打开容器内终端，执行
code --list-extensions --show-versions确认已安装；再执行code --status查看是否有加载错误日志
最常被忽略的一点：Docker 镜像里没装 curl 或 wget，会导致 VSCode 自动下载扩展包失败，且错误藏在后台日志里，界面上只显示“正在安装…”无限转圈。
