家里有一台自建服务器，又申请了公网 IP 以后，我曾经尝试把整个开发环境迁移到服务器上。这样无论身在何处，只要能够连接服务器，就可以继续使用同一套依赖、配置和代码，不必在不同设备之间反复同步环境。
不过，最初折腾了一段时间后，我发现这套方案并没有想象中方便。远程环境虽然统一，但编辑、调试和文件管理的体验始终不如本地的 IntelliJ IDEA 或 VS Code，于是便暂时放弃了。
后来实习时，我又遇到了必须在远程服务器上开发的场景。例如训练模型需要使用服务器上的显卡，本地电脑只能编写代码，却无法直接运行和验证；如果完全依赖服务器中的 Vim，编辑体验对当时的我来说又过于痛苦。于是，我重新研究了几种远程开发方式，也逐渐找到了适合不同场景的选择。
一、JetBrains Gateway
JetBrains Gateway 可以将 IDE 的后端运行在远程服务器上，本地只负责界面展示和交互。它通过 SSH 建立连接，项目索引、代码分析、编译和运行等工作主要由服务器完成，整体体验与本地使用 JetBrains IDE 十分接近。
对于习惯 IntelliJ IDEA、PyCharm 或 CLion 的开发者来说，这种方式的迁移成本很低。代码补全、跳转、重构和调试等功能都比较完整，也不需要为了远程开发重新学习一套编辑器操作。
它的主要问题是授权成本。部分远程开发能力需要对应的付费版本，虽然学生可以尝试申请 JetBrains 的教育授权，但并不是所有人都满足条件。对我而言，既不打算使用破解版，也暂时没有购买订阅的需求，因此最终没有选择这套方案。
适合场景： 已经购买 JetBrains 产品，重度依赖代码分析、重构和图形化调试能力，并且希望远程开发体验尽可能接近本地开发。
二、VS Code Remote SSH
VS Code 可以通过 Remote - SSH 扩展直接连接远程服务器。连接成功后，本地 VS Code 负责界面展示，代码、终端和大部分扩展则运行在服务器端。对于日常开发来说，它已经能够满足绝大多数需求。
这套方案免费，配置也比较简单。如果本地已经安装 VS Code，通常只需要准备好 SSH 登录信息，就可以直接打开服务器上的项目。代码补全、文件搜索、终端和调试等功能也比较齐全，是几种方案中最容易上手的一种。
它的问题主要出现在连接和初始化阶段。首次连接时，VS Code 需要在服务器上安装对应组件；之后打开项目，还可能需要加载扩展、建立索引并分析代码。当服务器性能较弱或当前负载较高时，这个过程会比较慢，偶尔还会出现长时间停留在连接或初始化阶段的情况。
如果服务器性能足够，并且日常开发仍以传统 IDE 操作为主，我认为 VS Code Remote SSH 是最均衡的选择。
适合场景： 希望免费获得完整的图形化开发体验，服务器性能尚可，并且主要使用电脑进行远程开发。
三、code-server
code-server 可以理解为部署在服务器上的网页版 VS Code。服务启动后，只要浏览器能够访问对应地址，就可以打开项目、编辑代码并使用终端。
它最大的优点是不依赖本地开发环境。即使临时使用一台没有安装 VS Code 的电脑，或者只有平板，也可以通过浏览器进入开发环境。这种方式很适合临时查看项目、修改配置或处理少量代码。
不过，浏览器中的操作体验与桌面版 VS Code 仍有一些差距，快捷键也可能与浏览器或操作系统发生冲突。此外，code-server 的终端拥有服务器上的实际操作能力，如果直接暴露到公网，一旦认证配置不当，就相当于把服务器入口交给了别人。因此，部署时至少需要配置可靠的身份认证和 HTTPS，也可以只允许通过 VPN 或 SSH 隧道访问。
对我来说，code-server 更像是一个备用入口，而不是长时间开发时的第一选择。它真正方便的地方，是让我可以在没有完整开发环境的设备上临时处理问题。
适合场景： 需要跨设备访问开发环境，偶尔使用平板或公共电脑处理代码，并且有能力妥善配置访问控制。
四、tmux + LazyVim
在 AI 辅助编程逐渐成为常态以后，我编写代码的方式也发生了变化。很多时候，代码由 AI 完成初步生成，我主要负责阅读、验证和修改；真正需要手动处理的内容，往往只是配置文件、参数或少量业务逻辑。
在这种工作方式下，完整的图形化 IDE 不再是每次都必需的。通过 SSH 登录服务器后，使用 tmux 管理终端会话，再配合 LazyVim 编辑代码，已经可以覆盖大部分需求。例如，可以将 tmux 分为左右两个窗格：左侧运行 Codex，右侧使用 LazyVim 查看和修改代码；还可以再开一个窗口运行测试、查看日志或监控 GPU 状态。
tmux 的另一个优势是会话可以持续保留。即使本地网络中断或者关闭终端，服务器中的任务仍然能够继续运行，下次连接后再恢复原来的窗口即可。这对于模型训练、编译和长时间运行的脚本尤其有用。
这套方案的缺点同样明显：Vim 系列编辑器和 tmux 都需要学习快捷键，初期使用效率可能还不如普通终端。插件配置、剪贴板和终端兼容问题也需要花时间处理。因此，它更适合愿意长期使用终端工作流的人，而不适合只想立即获得完整 IDE 体验的人。
适合场景： 经常通过 SSH 工作，重视低资源占用和会话保持，主要负责阅读、审核与小范围修改代码，并且愿意投入时间学习终端工具。
五、如何选择
这四种方案并不存在绝对的优劣，真正的区别在于开发习惯、服务器性能和使用设备。
| 方案 | 主要优点 | 主要缺点 | 更适合的场景 |
|---|---|---|---|
| JetBrains Gateway | IDE 功能完整，接近本地体验 | 可能需要付费授权，资源占用较高 | 重度 JetBrains 用户、复杂项目开发 |
| VS Code Remote SSH | 免费、易用、图形化体验完整 | 连接和项目初始化可能较慢 | 大多数日常远程开发 |
| code-server | 只需浏览器，跨设备方便 | 体验略逊于客户端，需要重点考虑安全 | 临时访问、平板或轻量设备 |
| tmux + LazyVim | 资源占用低，会话可恢复，适合终端工作流 | 学习成本较高 | SSH 高频用户、AI 辅助开发、长任务 |
如果只是偶尔进入服务器修改代码，VS Code Remote SSH 通常最省心；如果需要在不同设备上随时访问项目，可以把 code-server 作为备用入口；如果已经深度使用 JetBrains 产品，并且愿意为完整体验付费，Gateway 会更顺手；如果日常工作逐渐转向 AI 生成、人工复核和终端操作，那么 tmux + LazyVim 可能是更轻量的组合。
六、我的选择
目前我更倾向于使用 tmux + LazyVim。一方面，它对服务器资源的要求比较低，通过普通 SSH 就能工作；另一方面，tmux 可以长期保留会话，很适合服务器上经常出现的训练、编译和日志查看任务。再配合 Codex 处理代码生成与修改，许多工作不再需要启动完整的远程 IDE。
不过，这并不意味着图形化工具已经没有价值。遇到需要大范围检索、复杂重构或图形化调试的项目时，我仍然会使用 VS Code Remote SSH。对我而言，远程开发提效并不是找到一个能够取代所有工具的方案，而是根据任务选择成本最低、最顺手的入口。