最近接了个活儿要把现在跑在本机的 docker 容器开发环境搬到远程服务器上还要让团队里几个同事都能用 vscode 直接连进去写代码。折腾了几天踩了不少坑把 vscode 远程连接 docker 容器这件事彻底搞明白了。今天把整个思路和操作过程整理出来给同样被容器远程开发折磨的人一个能直接照着抄的完整方案。先说清楚这个东西是什么、能解决什么问题。vscode 远程连接 docker 容器简单说就是让 vscode 这位前端编辑器跟真正跑代码的后端环境分离你的代码、依赖、Python/C/Node 等解释器和编译环境全部打包在容器里而 vscode 的界面依然显示在你本地窗口。本地编辑保存后同步到容器在容器里执行命令、跑调试器、看端口服务体验跟本地开发几乎一样。适合谁用第一团队需要统一开发环境不想再出现我本地能跑你本地跑不了这类经典问题第二容器里装了一堆服务比如 MySQL、Redis、消息队列你不想把本地环境搞乱第三远程服务器上的 GPU 或大内存资源是开发刚需但你又不想用裸的 vim/tmux 硬扛。这篇文章我会先做方案选型对比然后给两种主流的连接方式最后是一堆实际踩坑后的排错记录。1. 整体思路与方案选型先搞懂四种连接方式别上来就装插件一开始我直接搜vscode 远程连接 docker 容器往往搜出一堆模糊的说法其实主流方案就四种我逐个试过之后从实用角度给你做个结论VSCode Dev Containers 插件直接附加到运行中的容器。这是最顺滑的方式前提是你的容器已经在某个机器上跑起来了vscode 可以把它当作一个远程开发环境直接打开。不需要在容器里额外装 SSH 服务配置透明。Remote-SSH 连接宿主机再通过 SSH 进入容器。这种方式本质是把宿主机当成跳板vscode 先连宿主机然后在终端里用docker exec -it进容器。缺点是插件和语言服务都跑在宿主机上容器里的环境并没有被 vscode 直接识别体验打折扣。在容器内启动一个 SSH 服务vscode 直接用 Remote-SSH 连接容器。这个方案最通用因为它的表现和连接一台远程 Linux 一样不管你在哪个网络里只要端口映射出来配置好密钥就能连。我最终在团队里推的就是这个。Dev Containers 配合 devcontainer.json 从零构建并打开容器。这种方式适合标准化的新项目可以在配置里声明基础镜像、需要安装的插件、端口映射等然后由 vscode 自动构建或者重用镜像生成一个独立的开发容器。适合项目初始化阶段。为什么这文章里我主要展开方案 1 和方案 3因为方案 2 不解决容器内开发体验这个核心诉求方案 4 对已有容器环境改造成本高还不如把容器先跑起来再附加。方案 1 和方案 3 覆盖了 90% 的真实场景本地 Docker Desktop 开发、远程服务器容器开发。我先从原理上解释一下vscode 远程开发并不是把整个软件界面传过去它会在远端安装一个vscode-server然后本地 vscode 通过一个通信通道把 UI 事件和文件内容同步过去。Dev Containers 插件做的就是把vscode-server装进容器里Remote-SSH 则是把vscode-server装进 SSH 连接到的目标机器里。理解了这点你就明白为什么容器里没有 bash、没有 wget会导致远程开发失败——因为它根本没法下载安装服务端组件。选型时还要看你的镜像是不是精简版。如果容器是alpine或者更极端的distroless方案 1 也会失败因为连 shell 都没有Dev Containers 没法初始化。所以在选方式之前先确定镜像类型、容器是否在运行、网络端口是否可达。下面我把两种主要方式的实操流程完整写一遍。2. 方式一Dev Containers 插件直接附加运行中的容器这个方法最适合容器已经在跑我想马上把它变成开发环境的场景。不需要改 Dockerfile不需要在容器里装 SSH只需要本地装有 Docker 环境Windows/macOS 用 Docker DesktopLinux 直接用 Docker Engine并且 vscode 能访问到对应的 Docker socket。2.1 前置条件与插件安装本机 vscode 需要装两个扩展Docker和Dev Containers扩展 ID 分别是ms-azuretools.vscode-docker和ms-vscode-remote.remote-containers。装好后左侧会出现 Docker 图标点开能看到本机和远程 Docker 上下文里的所有容器。如果你操作的是远程机器上的容器需要在 Docker Desktop 或者 Docker CLI 里先把 context 切到远程。例如远程服务器 IP 是192.168.1.10端口 2375 已经开启注意 2375 是明文端口生产环境一定要加 TLS否则等于把 Docker 权限公开给网络docker context create remote-server --docker hosttcp://192.168.1.10:2375 docker context use remote-server执行完docker context ls看到当前 context 带星号然后 vscode 里 Docker 面板就会显示远程机器上的所有容器。这里有个重要经验不要用 2375 明文端口暴露到公网至少要限制来源 IP否则别人能通过 Docker API 控制你的机器。我一般在生产环境用 SSH tunnel 来访问本地执行ssh -N -L 2375:localhost:2375 userremote-server这样本地 2375 端口只是 SSH 隧道的一个入口安全很多。2.2 附加到容器的完整操作流程在 Docker 面板里找到正在运行的容器右键点击容器选择 Attach to Container。vscode 会自动开始初始化过程窗口底部会提示 Installing VS Code Server这个过程是在容器内下载与本地 vscode 版本匹配的 server 组件需要网络访问外网。初始化完成后左下角会显示类似Container 容器名的状态此时左下角的远程状态等于容器。打开终端Ctrl会发现终端直接进入了容器 shell此时就能执行python、node、pip install等命令了。有一点要注意Dev Containers 附加时默认工作区是/workspace或者容器的WORKDIR目录而不是你宿主机上的项目路径。如果你的容器启动时通过-v /host/data:/srv/code挂载了宿主机目录建议在 vscode 界面里直接File Open Folder选择/srv/code这样才能看到你的项目文件。实际操作中还有一个高频需求附加到容器后vscode 的扩展是独立的不会继承本地已安装的一些扩展比如 Python、Prettier。你需要在容器里重新安装或者在.devcontainer/devcontainer.json文件里声明。如果只是临时附加我一般直接在扩展面板搜索安装vscode 会记住这个容器用的扩展集下次 attach 会自动带上。2.3 用 devcontainer.json 固化容器的开发环境如果你的项目要长期维护强烈建议不要用手动 attach 再手动装扩展这种临时方案而是在项目根目录建一个.devcontainer/devcontainer.json文件。它的作用是在从 Dockerfile 或 image 创建设开发容器时告诉 vscode 应该做什么。比如下面这个例子{ name: my-project-dev, build: { dockerfile: Dockerfile, args: { VARIANT: 3.11 } }, settings: { python.defaultInterpreterPath: /usr/local/bin/python }, extensions: [ ms-python.python, esbenp.prettier-vscode, dbaeumer.vscode-eslint ], forwardPorts: [8000, 3000], postCreateCommand: pip install -r requirements.txt, remoteUser: vscode }当你在 vscode 命令面板执行 Rebuild and Reopen in Containervscode 会根据这个文件构建镜像并启动一个容器容器内自动装好扩展执行postCreateCommand并把forwardPorts里声明的端口自动映射到本地这样你本地访问http://localhost:8000就能直接打开容器里跑的服务。这个文件是可以提交到代码仓库的新同事拉下来直接一键打开环境完全一致这才是Container as Environment的终极形态。这里我要特别说一个容易踩的坑extends和image/build不能同时乱配。如果你用 Dev Containers 的 Clone Repository in Container Volume 功能它会创建一个命名 volume 并把仓库 clone 进去此时即使 Dockerfile 里写了挂载也不生效因为源代码不在你宿主机路径下而在 docker volume 里。很多新手用这种方式以为能在宿主机改代码结果发现改的是 volume 里的副本一脸懵。建议除非你明确想要隔离环境并放弃本地直接编辑否则用 bind mount 方式让容器内的代码路径和宿主机一致见下面这个配置片段mounts: [ source${localWorkspaceFolder},target/workspace,typebind ]3. 方式二容器内启动 SSH 服务用 Remote-SSH 直接连接Dev Containers 虽然方便但有个限制它需要 vscode 能够直接控制 Docker daemon。如果你是远程服务器Docker daemon 没有对 vscode 开放端口或者只给你了一个普通的登录用户名密码没有操作 Docker 的权限那 Dev Containers 就玩不转了。这时候在容器里跑一个 SSH 服务让 vscode 用 Remote-SSH 连进去是更通用、更像连接一台远程 Linux 机器的做法。我在团队里最终采用了这个方案因为运维只给了容器映射端口不允许我们碰 Docker daemon。3.1 容器内安装并配置 sshd如果你的容器是基于 Ubuntu/Debian/CentOS 的普通镜像大概率没有安装 sshd需要自己装。以 Ubuntu 镜像为例启动容器时先以 root 身份进去安装apt update apt install -y openssh-server sudo mkdir -p /var/run/sshd echo root:yourpassword | chpasswd # 如果允许 root 登录需要修改 sshd 配置 sed -i s/#PermitRootLogin prohibit-password/PermitRootLogin yes/ /etc/ssh/sshd_config然后启动 SSH/usr/sbin/sshd验证一下 22 端口是否监听netstat -tlnp | grep :22如果容器是alpine镜像命令变成了apk add openssh-server配置路径也可能有差异但原理一样。要注意的是这种手动在容器里启动 sshd的方式跟容器生命周期的管理有冲突容器一重启sshd 不会自动启动除非你在 Dockerfile 里用CMD或入口脚本把 sshd 作为前台进程启动。所以正确做法是写一个启动脚本最后一行执行exec /usr/sbin/sshd -D让 sshd 在前台运行这样容器进程就是 sshd不会被系统杀掉。我之前就是因为图省事手动sshd容器 exit 再 start 后就连不上了排查了半天才发现是进程没起来。3.2 容器端口映射与 vscode 连接配置光在容器里跑了 sshd 没用宿主机的 vscode 要能访问容器的 22 端口必须做端口映射。在启动容器时加上-p 宿主机端口:容器端口参数docker run -d --name dev-container \ -p 2222:22 \ -v /my/project:/workspace \ my-image:latest宿主机映射到 2222 端口这是为了避免和宿主机的 22 端口冲突。然后用 vscode 的 Remote-SSH 扩展新建一个 SSH 配置Host dev-container HostName 192.168.1.10 Port 2222 User root确保~/.ssh/config里有这一段然后 vscode 里执行 Remote-SSH: Connect to Host选择dev-container输密码连接成功后进入容器环境。这个体验基本等价于直接连接一台远程主机只不过这台主机是容器而已。如果是本地 Docker Desktop端口映射后HostName填localhost或127.0.0.1即可。要注意 Windows 下如果用 WSL2 后端容器端口不会被动态映射到 localhost 的某些老版本需要先确认localhost:2222能否访问。我遇到过的现象是curl localhost:2222返回Connection refused但用 WSL 的 IP 就能通后来发现需要开启 Docker Desktop 的 Expose daemon on tcp://localhost:2375 以及把 WSL 网络镜像模式关掉才恢复正常。容器内 SSH 连接最容易忽略的是 shell 环境。vscode 的 Remote-SSH 会通过 SSH 执行命令这需要容器里有bash或者至少sh。如果是精简镜像没有 bash推荐先安装 bash否则后续很多扩展会找不到解释器。还有就是这个方案里面本地的 vscode 扩展也会自动安装在容器里不要惊讶这是远程开发的标准行为插件跑在远端才能感知远端文件系统所以你需要重新确认一下常用扩展是否可用。3.3 免密登录与安全加固别再用密码硬扛用密码连接每次都要输很烦而且密码在网络里明文传输除非你用密钥连接SSH 协议本身也允许密码传输但容易被抓包风险高。我建议直接配置密钥免密登录。在本地生成密钥然后把公钥放到容器里ssh-keygen -t ed25519 -C vscode-dev -f ~/.ssh/id_ed25519 cat ~/.ssh/id_ed25519.pub在容器内执行mkdir -p ~/.ssh echo 粘贴刚才的公钥 ~/.ssh/authorized_keys chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys然后修改/etc/ssh/sshd_config保证这几项PubkeyAuthentication yes PasswordAuthentication no PermitRootLogin prohibit-password重启 sshd。此后 vscode 连接就不再要密码还可以在 SSH config 里加入IdentityFile ~/.ssh/id_ed25519这样连接过程更快。公钥配置完以后有个不容易察觉的坑如果你在容器里是用 root 用户连接的但平时开发用的是普通用户那普通用户目录下的.ssh也要配好否则以普通用户连接时还是会被要求输密码。最好的做法是明确一个开发用户比如vscode然后所有 SSH 配置都在这个用户目录下做而不是偷懒用 root。安全方面再啰嗦一句容器里的 sshd 暴露到宿主机外部等于是多了一个攻击面。建议至少做到以下几点不要暴露 sshd 到公网除非你有防火墙和 fail2ban使用密钥而不是密码容器用户使用普通权限用户不要用 root宿主机上只映射一个非标准端口减少扫描攻击。这些措施很容易实现但能规避大部分风险。4. 核心细节拆解网络、端口、vscode-server 与容器环境的匹配两种方式都介绍完了我再来把几个文档里不会明说但是决定成败的细节单独拆开讲。4.1 vscode-server 的下载与离线安装前面说过vscode 远程连接时会在远端安装一个跟本地版本完全一致的vscode-server。这个 server 需要从微软的服务器下载容器环境如果没有外网或者 DNS 有问题就会卡在 Downloading VS Code Server 永远不动。解决办法有两个第一给容器配代理这需要你和网络管理员协调第二一次性手动安装到容器目录里。手动安装的思路是根据 vscode 左侧“关于”里的 commit id去https://update.code.visualstudio.com/commit:你的commit/server-linux-x64/stable下载对应的 tarball然后解压到容器的~/.vscode-server/bin/commitid/目录下并对目录做权限修正。这个方法我第一次用的时候觉得非常原始但在内网环境里几乎是唯一解。要注意的是容器如果基于alpineserver-linux-x64这个包可能起不来因为 vscode-server 依赖 glibc而 alpine 用的 musl libc 不兼容。此时要么换用官方 Ubuntu 镜像做开发容器要么使用server-linux-alpine版本的包但我实测只有老版本 vscode 提供 alpine 包新的 vscode 已经放弃官方支持。所以结论是远程容器开发别用 alpine否则等着被各种依赖问题折磨到崩溃。4.2 端口转发与多容器共存开发者经常需要同时连多个项目容器前端容器、后端容器、数据库容器。如果用方式一Dev Containersvscode 可以同时附加多个窗口每个窗口对应一个容器。如果用方式二Remote-SSH那你需要为每个容器映射不同的宿主机端口并在 SSH config 里维护多段配置。比如后端容器映射 2222前端容器映射 2223数据库一般不直接 SSH而是通过应用连接。端口转发有很多细节vscode 的forwardPorts可以把容器里的端口自动映射到本地但只对用 Dev Containers 创建/打开的容器有效用 Remote-SSH 方式连接容器时vscode 默认不会做“容器内端口到本机”的转发而是把 SSH 会话所在的远端端口转发到本地。那怎么让容器里的 8000 端口转发到本地 8000 端口最简单是在手机上执行ssh -N -L 8000:localhost:8000 dev-container这个命令的意思是在本地建立 SSH 隧道把本地 8000 端口收到的流量通过 SSH 隧道转发到容器dev-container的 localhost:8000。这样你在本地浏览器访问http://localhost:8000就能打开容器内服务。4.3 文件同步与 Git 配置vscode 远程开发时没有“文件同步”这个过程因为你的文件直接读取的是远端文件系统。如果你在容器里用 bind mount 挂载了宿主机代码目录那么在容器里修改文件就等于在宿主机修改文件反过来也一样这是双向实时的。但我提醒一下权限问题容器内非 root 用户如果对挂载目录没有写权限你会发现在 vscode 里保存文件就报错。解决方法是启动容器时指定用户 UID同时调整目录属主docker run -d --user $(id -u):$(id -g) -v /my/project:/workspace ...可以把当前宿主用户的 UID/GID 传进去容器内开发用户也要有相同的 UID否则还是会有权限问题。Git 配置这一块容易忽略的是容器里的 git 默认没有你的 user.name 和 user.email提交代码时会报错。可以在 devcontainer.json 里加入postCreateCommand: git config --global user.name YourName git config --global user.email youexample.com同时要注意 SSH key 在容器里不可见如果你想从容器直接 push 到 GitHub 或 GitLab需要在容器里重新生成密钥并添加到代码托管平台或者把宿主机的~/.ssh挂载到容器里。挂载密钥有风险但比密钥复制到容器里更灵活我一般这么挂载-v ~/.ssh:/home/vscode/.ssh:ro然后要给容器内用户设置密钥文件所有权也有点绕。更稳妥的做法是使用 vscode 的 Remote - SSH 插件时让 vscode 在宿主机执行git再通过File Sync之类的扩展做同步但那是另一套机制了。我个人的习惯是代码提交尽量在宿主机做容器只负责跑服务避免容器内密钥管理造成安全隐患。5. 实操过程与核心环节实现完整跑通一个远程开发环境接下来我以“远程服务器上的一个容器我要用 vscode 连进去开发一个 Python 项目”为例把从零到能写代码的整个过程过一遍。这是一个可以直接照做的完整实战。5.1 服务器端准备 Docker 容器服务器 IP 为192.168.1.100用户通过密钥登录服务器。首先在服务器上拉取 Python 基础镜像docker pull python:3.11-slim启动容器时至少要准备好三样东西项目目录挂载、SSH 端口映射、sshd 进程管理。我建议用一个 startup.sh 来做入口#!/bin/bash # 启动 sshd /usr/sbin/sshd # 进入工作目录 cd /workspace # 保持容器运行如果有前台服务可以 exec tail -f /dev/null镜像里的 Dockerfile 大致这样FROM python:3.11-slim RUN apt-get update apt-get install -y openssh-server sudo curl wget git \ mkdir -p /var/run/sshd \ echo root:changeme | chpasswd \ sed -i s/#PermitRootLogin prohibit-password/PermitRootLogin yes/ /etc/ssh/sshd_config \ useradd -m -s /bin/bash dev echo dev:devpass | chpasswd \ adduser dev sudo COPY startup.sh /usr/local/bin/startup.sh RUN chmod x /usr/local/bin/startup.sh WORKDIR /workspace CMD [/usr/local/bin/startup.sh]构建并启动docker build -t py-dev-image . docker run -d --name py-dev \ -p 2201:22 \ -v /home/user/project:/workspace \ py-dev-image启动后先确认容器状态docker ps ss -tlnp | grep 2201这里2201是宿主机上对外的 SSH 端口。5.2 本地 vscode 配置 Remote-SSH本地编辑~/.ssh/config添加Host py-dev HostName 192.168.1.100 Port 2201 User dev IdentityFile ~/.ssh/id_ed25519保存后在 vscode 命令面板输入Remote-SSH: Connect to Host选择py-dev。首次连接时vscode 会检测到目标机器没有 vscode-server自动下载。如果下载卡住就用 4.1 节里的手动方式处理。连接成功后vscode 左下角会显示SSH: py-dev。然后File Open Folder输入/workspace回车。右侧资源管理器就会显示项目文件。打开 Python 文件vscode 会提示没有 Python 解释器点击选择解释器远端机器上/usr/local/bin/python会自动出现。如果没出现可能是 Python 扩展没装到远端到扩展面板搜索ms-python.python点击 Install in SSH: py-dev。5.3 配置 Python 调试与终端环境要让 F5 调试能直接用可以在项目根目录创建.vscode/launch.json{ version: 0.2.0, configurations: [ { name: Python: 当前文件, type: python, request: launch, program: ${file}, console: integratedTerminal, cwd: ${workspaceFolder} } ] }在终端里pip install -r requirements.txt的时候要注意容器内的 pip 缓存如果不挂载每次重建容器都要重新下依赖。所以可以考虑启动容器时加参数-v pip-cache:/root/.cache/pip用命名 volume 持久化 pip 缓存省时省力。到这里你已经拥有一套完全跑通的 vscode 远程容器开发环境本地窗口操作远端容器执行代码挂载在宿主机目录团队其他人可以随时复用这个镜像和配置。整个流程我测下来大概二十分钟能走完如果网络下载 vscode-server 顺利的话。6. 常见问题与排查技巧实录下面是我和我同事在实际使用中踩过的一些典型问题按出现频率从高到低排列每一条都给出排查路径可以直接当速查表用。6.1 vscode 一直卡在 Installing VS Code Server 或者报下载失败这是最常见的问题原因 99% 是远端环境无法访问 vscode 更新服务器。先确认网络curl -I https://update.code.visualstudio.com如果超时说明没外网。解决办法要么配置代理要么手动下载并解压。我提供一个离线安装脚本思路在容器内执行mkdir -p ~/.vscode-server/bin/commit-id tar -xvzf vscode-server-linux-x64.tar.gz -C ~/.vscode-server/bin/commit-id --strip-components1 touch ~/.vscode-server/bin/commit-id/0注意最后这个0文件vscode 会用它作为“server 已安装”的标记没有它 vscode 会反复尝试重新安装。这个细节文档里没有但实际非常管用。6.2 Remote-SSH 能连上终端但打不开文件/无法远程编辑出现这种情况大多是 vscode-server 与本地版本不匹配或者~/.vscode-server目录权限不对。先看日志vscode 菜单 帮助 切换开发人员工具或者输出面板里选择 Remote - SSH。常见错误是lock文件残留导致 server 启动失败可以尝试删除远端~/.vscode-server/bin下的临时目录后重连。再就是权限问题比如你 SSH 连接用户是dev但~/.vscode-server的所有者是root那就用 root 连接一次先初始化或者直接chown -R dev:dev ~/.vscode-server。6.3 容器里装好 sshd 了但本地连接报 Connection closed by remote host这个问题大概率是 sshd 启动后很快退出。用模板容器启动时sshd 需要privileged模式或者至少要/var/run/sshd目录存在。检查ps aux | grep sshd journalctl -u sshd # 容器里可能没有 systemd用 /var/log/auth.log如果发现 sshd 挂了最直接的办法是回到docker exec -it 容器名 bash然后前台运行/usr/sbin/sshd -D观察报错。我遇到过一次是缺少host key解决办法ssh-keygen -A重新生成 host key 后启动 sshd 就好了。更隐蔽的问题是在容器里把PasswordAuthentication no配了但 authorized_keys 又是空或者权限 777vscode 连不进去还只提示连接被关闭。这时要检查 authorized_keys 权限配合 6.4 一起看。6.4 已配置公钥但连接还是要求输密码这一步很多新手会卡。原因是开启了StrictModessshd 会严格校验文件权限只要~/.ssh/authorized_keys权限对组用户或者其他用户可写sshd 就拒绝使用它。所以一定要执行chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys另外用户主目录本身如果被其他用户写权限也可能引发同样的问题确保~目录权限为 755 或 700 都可以。如果检查后还是不行用ssh -vvv devhost -p 2201查看详细输出看Offering public key后的反馈能看到 sshd 拒绝公钥的原因。6.5 容器内能跑命令但 vscode 集成终端键盘输入卡顿/中文显示乱码卡顿多是网络延迟或 sshd 的 KexAlgorithms 协商慢的问题。可以优化 SSH 配置Host py-dev GSSAPIAuthentication no ServerAliveInterval 60 IPQoS throughput中文乱码通常是容器没有安装中文字体或 locale 不对在 Dockerfile 里加RUN apt-get install -y locales \ locale-gen en_US.UTF-8 zh_CN.UTF-8 ENV LANGzh_CN.UTF-8不过这里提醒一句终端乱码多数情况是客户端字体问题跟远程关系不大本地 vscode 设置terminal.integrated.fontFamily: Noto Sans Mono CJK SC更直接。6.6 断网重连后vscode 卡在 ReconnectingSSH 通道断掉后vscode 会自动重连但如果长时间卡住直接重新执行 Remote-SSH: Connect to Host 并不会干净断开旧会话。最彻底的办法是在本地终端执行ssh -O exit py-dev关闭复用的 SSH 连接然后重新连。如果还不行在远端把残留的 vscode-server 进程清理掉pkill -f vscode-server之后重连vscode 会启动一个全新的 server 进程。7. 方案对比与最终经验心得最后把几种方案放在一起给想要直接上手的人一个决策表你的场景推荐方案配置复杂度适合团队本地 Docker Desktop 已有容器想快速进入容器开发Dev Containers 附加到容器低单人快速调试新项目从零搭建希望一键克隆环境Dev Containers devcontainer.json中全员统一环境远程服务器只能提供 SSH 端口容器内部自建服务容器内 SSH Remote-SSH中高运维限制较多的团队已有容器但镜像精简alpine无法装 server不建议远程开发换基础镜像--根据我个人经验如果权限足够首选还是 Dev Containers因为它在语义上最贴近“代码运行在容器里”这个目标端口转发、环境变量、工作目录都由 vscode 接管你不用手动维护 SSH 密钥和端口映射光是这一点就能省下很多维护成本。只有在你的网络环境或运维策略不允许直接操作 Docker daemon 时再退回到容器内 SSH 方案。还有一个很实用的小技巧无论用哪种方案都可以在项目根目录放一个.vscode/settings.json为这个项目固定解释器、格式化器、调试配置等这样不管是谁打开项目vscode 都会加载相同的设置{ python.defaultInterpreterPath: /usr/local/bin/python, [python]: { editor.defaultFormatter: ms-python.black-formatter, editor.formatOnSave: true }, python.linting.enabled: true }这种配置文件随代码走的思想才是远程容器开发最核心的收益——环境不再是某个人脑中的知识而是可以被任意新人拉下来直接使用的资产。踩过这么多坑之后我有一个很深的体会vscode 远程连接 docker 容器本质上就是在处理远程机器上能不能顺利跑一个 vscode-server这个问题而影响这个问题的变量无非是网络、权限、基础镜像环境这三件事。先把这三件事都验证清楚再动手配置你会少走很多弯路。希望这篇文章的细节能帮到你尤其是里面那些文档不会写但实际一定会遇到的经验。