VS Code 安装这事本身没什么门槛，真正卡人的是后半截——把它连到远程服务器上。我见过太多人卡在同一批地方：私钥权限没改，SSH 一直报 too open；~/.vscode-server下载不下来，界面停在 “Setting up SSH Host” 转圈；连着连着窗口断线，重连发现后台任务全没了。这篇就围绕VS Code 安装 + 远程服务器开发环境这条线，把本地装什么、服务器开什么、SSH 怎么配、连不上怎么查，按我自己的实际操作顺序捋一遍。不管你是刚买第一台云主机的新手，还是手上管着几台内网机器、想统一开发环境的老手，都能从里面找到能直接照做的东西。我不打算写成产品说明书，只讲那些年我在工位上真踩过的坑，以及每个坑背后为什么会出现。
1. 先想清楚：为什么要把编辑器搬到远端
1.1 本地写代码、远端跑程序的真实动机
很多人第一次接触远程开发，动机其实很朴素：代码在服务器上，本地只是个入口。但这个“入口”值不值得搭，得想清楚。
最常见的场景是算力和环境的不对称。你手上是一台轻薄本，编译一个稍大的工程风扇就起飞；而远端那台机器有 32 核、128G 内存，硬盘还是 NVMe。这时候把代码同步到本地、改完再传回去，中间多了一道手工活，还极易出现“本地改了 A 文件、传上去覆盖了服务器上别人改的 B 文件”这种事。远程开发把这个来回彻底删掉了——文件始终在远端，编辑器通过 SSH 通道读写，你看到的就是服务器上真实的那份。
第二种场景是环境一致性。一个项目依赖特定版本的解释器、特定的系统库、特定的编译工具链，这些你在本地配一遍、在服务器再配一遍，两份配置迟早会漂移。而远程开发天然只有一份环境，跑得通就是跑得通，不存在“我这儿是好的”。
第三种是长任务的连续性。训练模型、跑数据清洗、编译大型项目，动辄几十分钟。本地机器一合盖就断，远端机器不睡。配合 tmux 之类的会话保持工具，关掉编辑器任务照跑。
我自己的判断标准很简单：如果这个项目的代码最终要跑在一台我无法随身带的机器上，那就值得把编辑器也搬过去。否则本地开发更省事。
1.2 三种常见方案的横向对比
远程开发不是只有一条路，常见的有三种，各自适用面差别很大。
| 方案 | 原理 | 优点 | 明显短板 |
|---|---|---|---|
| 纯 SSH 终端编辑（vim/nano） | 直接在远端终端里改 | 零依赖，任何机器都能用 | 补全、跳转、重构能力弱，大项目效率低 |
| 本地编辑 + 同步工具上传 | 本地改完自动/手动传 | 本地体验流畅，断网也能写 | 有同步延迟和冲突风险，环境仍是两份 |
| 编辑器远程开发（本文主线） | 编辑器分前后端，UI 在本地、逻辑在远端 | 体验接近本地，环境只有一份 | 依赖网络质量，首次连接要装服务端组件 |
表格里第三行的原理值得多说两句，因为理解了它，后面所有报错你都能自己推。这类远程开发并不是把整个编辑器“投屏”过来，而是拆成两半：本地只跑界面渲染和输入处理，语言服务、终端、调试器、文件读写全部跑在远端的一个小服务进程上。你在编辑器里敲一个字符，本地把事件发给远端，远端算完补全结果再发回来。所以网络延迟影响的是“手感”，而不是“功能有没有”。延迟 50ms 基本无感，超过 150ms 打字会有轻微滞后感。
1.3 这套方案的边界：什么情况别硬上
说优点的时候容易上头，我得泼点冷水。
网络质量差且无法改善的环境不适合。比如需要跨地域访问、链路抖动严重的场景，编辑体验会让人抓狂。这种时候不如老老实实本地开发，用 Git 做代码同步。
前端/图形界面为主的项目收益有限。这类项目的大量时间花在浏览器调试上，远程开发能帮你的主要是把本地端口转发出来预览，价值没那么大。
极度轻量的脚本修改没必要。改个配置文件、看个日志，直接 SSH 上去用tail -f更快，为这个装一整套远程开发环境是杀鸡用牛刀。
还有一个容易被忽略的点：远端机器的资源也不是无限的。远程开发会在服务器上常驻一个服务端进程，吃内存、吃 CPU、还会监视文件变化。在一台只有 1G 内存的小机器上同时开两三个远程窗口，很容易把机器拖垮。这一点后面讲性能调优时会专门说。
2. 本地安装：别小看这一步的选择
2.1 三个平台的安装路径与版本取舍
安装包从官方下载页拿就行，但下载页面上那几个选项，选错了后面会膈应很久。
Windows 平台有两个安装器：用户级（User Installer）和系统级（System Installer）。区别不在功能，而在安装位置和权限。用户级装到当前用户目录，不需要管理员权限，自动更新也不会弹 UAC；系统级装到 Program Files，所有账户共享，但每次更新要管理员权限。我的建议是：个人电脑一律用用户级，省心；如果是多人共用的工作站，用系统级，避免每个账户装一份。
安装过程中那个“添加到 PATH”的勾选框，务必勾上。不勾的话，命令行里敲code命令会找不到，后面想用命令行打开文件、做文件对比会很难受。安装完成后重新开一个终端验证：
code --version能打印出版本号和提交哈希就对了。这个提交哈希记一下，后面讲离线安装服务端组件时要用到，它是远端组件目录名的来源。
macOS 平台相对简单，下载 zip 解压后把应用拖进“应用程序”目录就行。装完记得做一步：在编辑器里按Cmd+Shift+P，输入Shell Command: Install 'code' command in PATH执行一次，否则终端里同样没有code命令。这一步很多人漏掉，然后在教程里看到code .一脸茫然。
Linux 平台的选择最多。桌面发行版用 deb 或 rpm 包最省事，仓库会自动处理依赖和更新。如果你用的发行版不在官方包管理范围内，压缩包版本也能用，解压后直接运行可执行文件，只是不会自动更新。
提示：不要从第三方下载站拿安装包。编辑器这类工具被二次打包塞东西的情况并不罕见，体积、哈希、签名都值得核一下。
2.2 首次启动必须改掉的五个默认项
装完之后直接开干，用久了会发现几处默认设置很别扭。这五项我每台新机器都会第一时间改掉。
第一项，自动保存。默认是关闭的，靠手动Ctrl+S。改成onFocusChange（切走窗口就保存）比afterDelay更符合直觉，避免出现“以为存了其实没存”的惨案。
第二项，文件编码与行尾。如果团队里有 Windows 和 Linux 混用，行尾不一致会在 Git 里制造大量假 diff。把默认行尾统一成 LF，编码统一 UTF-8，能省一堆事。
第三项，缩进检测。打开editor.detectIndentation，让编辑器根据文件内容自动判断用 Tab 还是空格。这个开关默认是开的，但有些安装包或同步过来的配置会关掉，值得扫一眼。
第四项，files.watcherExclude。这个和远程开发强相关。默认的文件监视器会盯着项目目录里所有变化，如果项目里有node_modules、构建产物、日志目录，监视器会被拖垮，表现为编辑器卡顿、CPU 占用高。提前把大目录排除掉：
{ "files.watcherExclude": { "**/node_modules/**": true, "**/dist/**": true, "**/build/**": true, "**/.git/objects/**": true, "**/logs/**": true } }第五项，终端默认 Shell。远程连接后终端用的是远端 Shell，但本地集成终端的默认 Shell、字体、光标样式这些，早点配好，省得每次重装都重新折腾。
2.3 必装插件清单与取舍理由
插件这事容易走两个极端：一个不装，或者装一百个。我倾向于按“解决什么问题”来装，而不是看到推荐就点。
远程开发的核心插件只有一个：Remote - SSH。装上它，命令面板里才会出现 “Connect to Host”、“Add New SSH Host” 这些入口。它还会顺带装一个配置编辑辅助插件，用来帮你格式化 SSH 配置文件。
围绕这个核心，我常备的还有几类：
- 语言相关：按你主力语言装，不要贪多。装三个语言的服务端插件，每个都在后台跑一个语言服务进程，内存占用是叠加的。
- Git 可视化：看行级变更、暂存部分代码很方便，尤其是 review 自己的改动时。
- 配置同步：如果你有多台机器，用账号同步或者手动同步配置文件，比一台台重配高效得多。
- 括号/缩进辅助：纯视觉增强，可选，但用了就回不去。
注意：在远程窗口里装插件时，编辑器会区分“装在本地”和“装在远端”。凡是要读取远端文件系统、调用远端运行时的插件，必须装在远端。装错位置的表现是插件显示已安装但完全不工作。
3. 服务器端准备：这一步偷懒，后面全是坑
3.1 账号、目录与权限的基本约定
远端这边的准备，本质是三件事：有个能登录的账号、有个放代码的目录、SSH 服务允许你连进来。
账号这块，我的习惯是给自己建一个普通用户，日常开发用它，不用最高权限账户直接连。原因很实际：很多服务端进程默认拒绝最高权限账户登录，而且用普通用户跑，误操作的影响范围小得多。需要提权的时候再单独提，别图省事。
目录这块，建议固定一个工作根目录，比如家目录下的work或projects。所有项目都放在这个根目录下，好处是后面配置files.watcherExclude、做备份、迁移机器时，路径是统一的，脚本不用改。
权限这块要特别小心，这是新手最常翻车的地方。SSH 对密钥文件的权限极其敏感：私钥文件必须只有属主可读，目录不能让其他人有写权限。权限一宽松，SSH 会直接拒绝使用这个密钥，报错信息还特别含糊。标准做法是：
chmod 700 ~/.ssh chmod 600 ~/.ssh/authorized_keys chmod 600 ~/.ssh/id_ed25519另外家目录本身也不能对同组或其他用户开放写权限，否则某些 SSH 配置下同样会被拒绝。检查一下：
ls -ld ~ # 期望看到 drwxr-xr-x 或 drwx------，不能是 drwxrwxrwx3.2 SSH 服务端关键配置逐条说明
服务端的配置文件通常在/etc/ssh/sshd_config。改之前先备份，改完先测语法再重启，这是保命的顺序：
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak sudo sshd -t # 语法检查，没有输出就是通过 sudo systemctl restart sshd里面值得关注的几项：
| 配置项 | 建议值 | 为什么这么设 |
|---|---|---|
Port | 改成非默认端口 | 减少自动化扫描带来的无效日志，降低干扰 |
PermitRootLogin | no | 最高权限账户直接对外登录风险高，用普通用户 + 提权更可控 |
PasswordAuthentication | 配好密钥后设no | 只允许密钥登录，杜绝暴力猜密码 |
PubkeyAuthentication | yes | 密钥登录的前提 |
AllowUsers | 显式列出允许登录的账号 | 白名单机制，比黑名单可靠 |
ClientAliveInterval | 60 | 每 60 秒发一次探测 |
ClientAliveCountMax | 3 | 连续 3 次无响应才断开，避免网络抖动误杀 |
MaxSessions | 10 | 限制单连接会话数，防止资源被单个连接吃满 |
ClientAliveInterval和ClientAliveCountMax这一对，是解决“编辑到一半连接莫名断开”的关键。默认配置下，空闲连接可能被中间网络设备回收，表现出来就是窗口突然变灰、提示连接已关闭，重连后终端里的历史输出全没了。设成 60×3，也就是 3 分钟内只要有一点活动就不会断。
MaxSessions这一项很多人不知道，但它和远程开发直接相关。编辑器在远端会开多个通道：一个跑文件服务，一个跑终端，一个跑语言服务。如果MaxSessions设得太小（有的老配置是 1），连上去就报通道创建失败。
3.3 密钥登录的完整配置流程
密钥登录是远程开发的地基，配好了后面所有事都顺。整个流程分四步，一步都别跳。
第一步，本地生成密钥对。用 ed25519 算法，比 RSA 短、快、安全性足够：
ssh-keygen -t ed25519 -C "dev-laptop-2024"-C后面是注释，写清楚是哪台机器、什么时候生成的。半年后你手上有五六把密钥，没有注释根本分不清哪把是哪把。保存路径直接回车用默认的，密码短语（passphrase）建议设一个——虽然每次连接要输一遍，但配合后续的密钥管理工具，安全性提升值得。
第二步，把公钥传到服务器。公钥文件是.pub结尾的那个，可以随便传；私钥是没后缀的那个，绝对不能离开本地。传的方式有两种：
# 方式一：有密码登录的情况下，用这条命令自动处理权限 ssh-copy-id -i ~/.ssh/id_ed25519.pub user@host # 方式二：手动追加到远端 authorized_keys cat ~/.ssh/id_ed25519.pub | ssh user@host "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"方式一更省事，它会自动处理目录和文件权限。方式二手动但透明，出问题时你知道每一步发生了什么。
第三步，验证。不要直接去编辑器里试，先用终端验证，把问题范围缩小：
ssh -i ~/.ssh/id_ed25519 user@host能免密进去就说明密钥链路通了。如果还问密码，说明公钥没被正确读取，去看服务端的/var/log/auth.log或/var/log/secure，那里会明确写“找不到匹配的密钥”或者“权限过宽被拒绝”。
第四步，关闭密码登录。确认密钥登录可靠之后，再去sshd_config里把PasswordAuthentication改成no，重启服务。这一步别提前做，否则密钥配错了你会被锁在门外，只能走控制台救援。
4. 打通连接：Remote-SSH 实操全流程
4.1 本地 SSH 配置文件的写法与字段含义
编辑器连接远端，底层就是调用系统 SSH 客户端。所以最可靠的做法是先把配置写进 SSH 配置文件，再让编辑器去读，而不是在弹窗里手填参数。
本地配置文件路径：Windows 是C:\Users\你的用户名\.ssh\config，macOS 和 Linux 是~/.ssh/config。文件不存在就新建一个，权限设为 600。
Host dev-box HostName 10.0.0.21 User worker Port 2222 IdentityFile ~/.ssh/id_ed25519 ServerAliveInterval 30 ServerAliveCountMax 6 TCPKeepAlive yes逐字段说一下为什么这么写：
Host是别名，后面你在编辑器里看到的就是这个名字，写个有意义的名字比记 IP 舒服得多。HostName才是真实地址，内网 IP、域名都行。User和Port对应服务端配置，端口如果改过必须在这里同步。IdentityFile指定用哪把私钥，多密钥环境下这一行是必须的，否则 SSH 会挨个试，试到被服务端限流。
后面三行是保活配置，也是解决断线问题的核心。ServerAliveInterval 30表示每 30 秒发一次保活包，ServerAliveCountMax 6表示连续 6 次没回应才断开。这和服务端的ClientAliveInterval是两端配合的关系，两边都配上，连接才真正可靠。TCPKeepAlive yes打开 TCP 层保活，防止中间的 NAT 设备把空闲连接表项清掉。
如果目标机器在内网，需要先经过一台可登录的中转机器，用-J参数就行，配置里对应写ProxyCommand或者直接用命令行的跳板语法。这里不展开，因为涉及网络架构，各家差异很大。
4.2 首次连接到底发生了什么
点下“连接”之后，编辑器的动作顺序大致是这样，理解了它，90% 的卡顿问题能自己定位：
- 用系统 SSH 客户端按配置发起连接，做密钥认证。
- 连接建立后，检测远端架构（x86_64、arm64 等）和已安装的组件版本。
- 如果没有匹配的服务端组件，就开始下载压缩包并解压到
~/.vscode-server。 - 启动服务端进程，建立多个数据通道。
- 本地界面接管，显示远端文件树。
第 3 步是最容易卡住的地方。表现是左下角一直显示 “Setting up SSH Host...”，下面还有一行“正在下载”转圈，几分钟后报超时。原因通常不是网络不通（SSH 都连上了），而是远端机器访问外部下载地址受限，或者磁盘空间不足。
这时候先做三件事：看磁盘够不够（df -h），看家目录下.vscode-server有没有生成，看编辑器输出面板里Remote - SSH那一路的日志。日志里会明确写出它在下载哪个地址、报了什么错。
顺便说个细节：组件是按版本隔离存放的。~/.vscode-server/bin/下面每个子目录名对应一个提交哈希，你升级一次编辑器，就可能多出一个目录。时间长了这些目录能占好几个 G，定期清理不用的版本很有必要。
4.3 受限网络下的组件离线安装
有些服务器出于安全策略，不允许访问外部下载地址。这种环境下的解法是离线安装：在能上网的机器上把压缩包下好，传到服务器上手动解压。
步骤是这样的。先从本地编辑器的“帮助 → 关于”里找到提交哈希，记下这一长串字符。然后在能上网的机器上下载对应架构的服务端压缩包，文件名形如vscode-server-linux-x64.tar.gz。传到服务器后：
# 建立以提交哈希命名的目录 mkdir -p ~/.vscode-server/bin/<提交哈希> # 解压并剥离顶层目录，让内容直接落在哈希目录下 tar -xzf vscode-server-linux-x64.tar.gz \ -C ~/.vscode-server/bin/<提交哈希> \ --strip-components 1 # 关键：创建一个标记文件，告诉编辑器这个版本已经装好了 touch ~/.vscode-server/bin/<提交哈希>/0最后那个0文件是很多教程漏掉的一步。没有它，编辑器会认为组件没装完，重新触发下载。这个文件的本质就是一个完成标记。
提示：压缩包的架构要和服务器一致。x86 的包扔到 arm 机器上，解压出来能看见文件，但一启动就报 “Exec format error”，这个错很容易被误判成组件损坏。
5. 连上之后：把远端环境调顺手
5.1 端口转发与本地预览
远端跑起来一个服务，本地想用浏览器看效果，这就是端口转发要解决的问题。编辑器会自动嗅探远端启动的服务端口，弹出提示问你要不要转发。转发之后，本地访问localhost:3000就等于访问远端的 3000 端口。
自动嗅探有时不灵，尤其是服务只绑定了远端的特定网卡地址、或者启动日志格式不常见时。手动加一条就行：打开端口面板，输入端口号，指定远端地址。
这里有个踩过多次的坑：服务必须绑定在可被转发访问的地址上。如果程序硬编码绑定到某个外部网卡 IP，转发往往抓不到，表现为远端curl能通、本地浏览器打不开。改法是把监听地址设为回环地址或全部地址，转发就能正常工作。
转发建立后，本地的调试工具、接口测试工具都能直接连这个端口，省去在服务器上装图形化工具的麻烦。
5.2 远程设置与扩展的存放位置
远程窗口里有两份设置：用户设置和远程设置。这个区分很重要，很多人改了半天设置不生效，就是因为改错了作用域。
- 用户设置：跟着你的账号走，本地远程都用，位置在本地。
- 远程设置：只对当前这台远端机器生效，存在远端，路径在
~/.vscode-server/data/Machine/settings.json。 - 工作区设置：跟着项目走，存在项目目录的
.vscode/settings.json里，会进版本库。
远程设置最适合放那些“跟这台机器强相关”的配置，比如远端解释器路径、远端工具链位置、终端默认 Shell 路径。工作区设置适合放团队共享的规范，比如格式化规则。
扩展同理，分本地和远端两套安装位置。语言服务、调试器、代码检查工具必须装在远端；主题、快捷键、界面增强装在本地就行。判断标准很简单：这个插件需不需要读写远端文件、调用远端进程。需要，就装远端。
5.3 多台机器与多账号的管理方式
手上机器一多，配置文件就会膨胀。我的组织方式是三层：
第一层，通用配置写在Host *下面，比如保活参数、压缩传输开关、默认使用的密钥列表。这样每台机器不用重复写。
第二层，按机器分组写别名。同一个项目的几台机器用前缀区分，比如proj-web、proj-db，一眼能看出归属。
第三层，用 Include 拆文件。配置文件支持Include指令，可以把工作相关、个人相关拆成不同文件，主文件里只有一两行引用。机器多了之后，这种结构比一个几百行的巨型配置文件好维护得多。
# 主配置文件 Include config.d/work-* Include config.d/personal-*多账号的情况还要注意密钥选择。同一个远端地址下用不同账号登录时，一定在Host块里明确写IdentityFile，不要让 SSH 自己猜。SSH 默认最多尝试有限次数的密钥，猜错了会直接失败，报 “Too many authentication failures”。
6. 排查实录：那些年卡住我的报错
6.1 连接阶段的典型问题
私钥权限过宽。报错大意是 “Permissions 0644 for xxx are too open”。这是 SSH 的保护机制，防止私钥被其他用户读取。Linux/macOS 上直接chmod 600解决。Windows 上麻烦一些，需要用文件属性里的安全设置，把继承权限关掉，只保留当前用户。
主机指纹变化。报错大意是 “REMOTE HOST IDENTIFICATION HAS CHANGED”。通常发生在机器重装、IP 被重新分配之后。确认是自己造成的，就删掉旧的记录：
ssh-keygen -R 10.0.0.21不确定原因的话，先别删。指纹变化也可能是中间人攻击的信号，尤其在你连的公网地址时。
连接被拒绝。分三种情况：端口没开（服务没启动或者防火墙拦了）、端口开了但账号不允许登录（白名单没加你）、账号密码或密钥错误。判断方法是从服务端看：systemctl status sshd看服务活着没，ss -tlnp看端口在不在监听，日志看认证失败的原因。别在本地反复重试，服务端日志一句话就能说清。
连上了但立刻断开。常见原因是家目录权限过大、磁盘满了、或者MaxSessions太小。查日志最直接。
6.2 连上之后的典型问题
服务端组件启动失败。如果服务器上的系统库版本偏旧（比如一些仍在服役的老系统，底层的 C 库只有 2.17），而编辑器版本较新要求更高的库版本，服务端进程就会起不来。日志里会写缺少某个库符号。解法有两条：把系统库升级到满足要求，或者用较旧版本的编辑器客户端连这台机器。后者更快，代价是不能享受新功能。
文件监视器报错。大仓库下经常看到 “Unable to watch for file changes” 之类的提示，本质是系统的文件句柄上限被触及。临时提高上限：
# 查看当前上限 ulimit -n # 临时提高 ulimit -n 65536永久生效要改/etc/security/limits.conf或者对应的配置目录。同时配合前面说的files.watcherExclude，双管齐下。
终端里中文乱码或颜色异常。远端LANG没设对。在远程设置里指定终端环境变量，或者直接在远端 Shell 的配置文件里设LANG，两种都行。
上传大文件失败。直接拖拽文件到远端资源管理器，走的是编辑器的通道，大文件容易超时。超过几十兆的文件，老老实实用scp或者rsync，还能断点续传：
rsync -avz --progress ./data.tar.gz user@host:~/work/data/6.3 问题速查表
| 现象 | 最可能的原因 | 快速验证方式 |
|---|---|---|
| 一直停在 Setting up，最后超时 | 远端无法下载服务端组件 | 看输出面板 Remote-SSH 日志，查下载地址 |
| 提示私钥权限过宽 | 私钥文件权限不是 600 | ls -l ~/.ssh/ |
| 报主机指纹变化 | 机器重装或 IP 变更 | 对比已知指纹，确认后ssh-keygen -R |
| 免密登录失败但密码能进 | 公钥没写进 authorized_keys，或权限不对 | 看服务端 auth 日志里的拒绝原因 |
| 编辑到一半连接断开 | 缺少保活配置，空闲连接被回收 | 检查两端 ClientAlive/ServerAlive 设置 |
| 远端终端起不来 | MaxSessions太小或 Shell 路径错误 | 服务端日志 + 手动 SSH 验证 |
| 服务端进程启动即退出 | 系统库版本低于要求 | 手工执行服务端启动脚本看报错 |
| 大仓库卡顿、CPU 高 | 文件监视器扫了太多目录 | 临时关闭监视，观察是否缓解 |
| 本地打不开远端服务端口 | 服务绑定了不可转发的地址 | 远端curl localhost:端口先确认 |
| 上传大文件中断 | 走编辑器通道有体积限制 | 改用rsync或scp |
7. 几个只有踩过才明白的细节
先说版本对齐这件事。本地编辑器版本和远端服务端组件的匹配关系，不是“向下兼容”那么简单。你升级了本地的编辑器，下次连远端会自动装新版本组件，旧目录留着不删。时间一长，~/.vscode-server/bin下面堆了七八个版本，占几个 G。定期清一下，只留当前在用的那个哈希目录，是很有必要的运维习惯。
再说长任务的会话保持。远程开发窗口关掉，远端跑在前台的任务会被一起带走。所以训练、编译这类耗时任务，一定放在 tmux 之类的会话里跑，编辑器只作为编辑入口。这个习惯我是在一次通宵编译跑到 90% 时网络抖动断连、重连后一切归零之后养成的。
还有一点关于多机协作时的配置文件管理。不要在每台机器上手动改配置，把settings.json、keybindings.json和一份插件清单放在版本库里，新机器上克隆下来直接铺开，五分钟能配好一台。这件事做过一次之后，你会发现以前每台机器折腾半天完全是浪费。
最后提一个容易被忽视的资源问题：远端常驻的服务端进程会一直吃内存。在一台内存紧张的机器上，同时开两三个远程窗口，再跑个数据库，很容易触发系统的内存回收，表现为整台机器变慢、SSH 响应迟钝。远端开发不是免费的，机器规格该给够就得给够，别指望在 1G 内存的小机器上做大项目开发。
