VSCode远程开发关键在选对扩展、理清路径、避坑权限网络：①Remote-SSH需本地OpenSSH可用且密钥认证；②devcontainer.json须置于.gitignore外的.project/.devcontainer/下并正确配置镜像与扩展；③WSL开发应直接用code命令触发原生支持，代码存WSL文件系统。
VSCode 的远程开发能力本身不依赖“教程式配置”，关键在于选对扩展、理清连接路径、避开权限和网络陷阱。
安装 Remote - SSH 扩展并验证基础连接
这是远程开发最常用的方式，但很多人卡在第一步：扩展装了却连不上。必须确认本地已安装 OpenSSH 客户端（Windows 10/11 用户需启用“OpenSSH 客户端”可选功能，macOS 和 Linux 一般自带），且 ssh 命令能从终端直接调用。
- 在 VSCode 扩展市场搜索并安装
Remote - SSH（作者 Microsoft） - 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Remote-SSH: Connect to Host...，首次使用需先配置config文件 - 配置项中不要写密码——用
ssh-keygen生成密钥对，并用ssh-copy-id user@host推送公钥；否则每次打开都会弹窗输密码，且无法启动后台服务 - 如果提示
Could not establish connection to "xxx"，先在本地终端执行ssh -T user@host测试连通性，排除防火墙、端口（默认22）、sshd未运行等底层问题
远程容器开发：用 devcontainer.json 统一环境
当目标机器没有预装 Node.js、Python 或特定版本时，硬配环境容易出错；用 Docker 容器封装开发环境才是稳定解法。VSCode 通过 devcontainer.json 驱动整个流程，但配置不当会导致扩展无法加载或路径映射失败。
MergeIQ: Automatically Score & Prioritise PR Complexity for GitLab and GitHub
下载
使用四维度框架评估任意 GitLab MR 或 GitHub PR 的复杂度：规模（20%），认知负荷（30%），审查工作量（30%），风险/影响（20%）...
-
devcontainer.json必须放在项目根目录的.devcontainer/文件夹下，文件名不能拼错，也不能放在子目录里 - 指定镜像时优先用
image（如"image": "mcr.microsoft.com/vscode/devcontainers/python:3.11"），避免用dockerfile自建——除非你明确需要定制构建步骤 - 挂载本地代码进容器要用
"mounts"或靠"workspaceFolder"自动映射；若容器内看不到文件，检查是否误设了"workspaceMount"覆盖了默认行为 - 安装的扩展（如 Pylance、ESLint）要写进
"customizations.vscode.extensions"数组，否则只在本地生效，容器里不识别
远程 WSL 开发：绕过 SSH 的轻量方案
如果你实际开发环境就是本机的 WSL2（比如 Ubuntu），完全没必要走 SSH 这层网络协议——VSCode 提供原生 WSL 支持，延迟更低、文件访问更快，但容易忽略两个前提条件。
- 必须在 WSL 中安装完整版 VSCode Server：运行
code .会自动触发，但如果 WSL 里没装curl或tar，下载会静默失败，表现为“正在启动服务器…” 卡住 - WSL 发行版需为 systemd-enabled（Ubuntu 22.04+ 默认支持），否则某些后台服务（如数据库、Redis）无法随容器启动，得手动
service xxx start - 不要在 Windows 文件系统（
C:\）里打开项目再用 WSL 远程——性能极差，且部分文件权限（如chmod +x）不生效；所有代码应放在 WSL 根文件系统（如/home/user/project）中
真正难的不是连上，而是让调试器、终端、Git 和扩展在远程上下文里行为一致。比如 Python 的 launch.json 中的 "python" 路径要指向容器或 WSL 里的解释器，而不是本地的；又比如 Git 提交时的用户名邮箱，得在远程环境里单独配置，不会自动继承主机设置。
