sublime text 本身不能在远程服务器上运行,所有编辑均在本地完成;所谓“远程运行”实为本地编辑后通过 post_upload_command 等机制调用 ssh 执行命令,不支持远程进程管理、终端集成或调试,能力远弱于 vs code remote-ssh。

Sublime 保存后自动 SSH 执行命令(最实用的轻量方案)
这是最贴近“运行远程服务器”的做法:编辑完本地文件 → 保存 → 自动通过 SSH 在服务器上执行 reload / build / test 等命令。
- 依赖
SFTP插件的post_upload_command配置项,仅在上传成功后触发 - 示例配置(写入
sftp-config.json):{ "type": "sftp", "host": "192.168.1.100", "user": "deploy", "remote_path": "/var/www/myapp", "upload_on_save": true, "post_upload_command": "ssh deploy@192.168.1.100 'cd /var/www/myapp && npm run build && systemctl reload nginx'" } - 注意:
post_upload_command是本地 shell 执行,不是远程 shell;所以必须确保本地能免密 SSH 登录目标服务器(ssh deploy@192.168.1.100不报 password 提示) - 若命令含单引号,需转义或改用双引号包裹整个字符串,避免 JSON 解析失败
- 不支持交互式命令(如
python manage.py shell),只适合无参、幂等、快速完成的脚本
rsub 能否让 Sublime “运行”远程代码?
不能。rsub 只负责把远程文件打开请求转发到本地 Sublime,它不启动任何远程进程,也不提供终端集成。
- 你在远程执行
rsub app.py,只是让本地 Sublime 打开该文件的副本,内容来自远程读取(一次性的) - 想“运行”它,仍需回到远程终端手动执行
python app.py或配好本地终端插件(如 Terminus)再连过去 - 常见误操作:
rsub启动后直接在远程跑subl app.py—— 这会失败,因为subl命令在远程没图形环境,且根本没装 Sublime -
rsub的端口(默认 52698)必须在本地开放且未被占用,否则状态栏不显示rsub: ready
为什么不能像 VS Code 那样直接“Remote Run”?
VS Code Remote-SSH 在远程启动了一个 vscode-server 进程,负责文件监听、终端管理、调试协议桥接;Sublime 没有对应机制,所有插件(包括 SFTP、RSub)都运行在本地,无法感知远程进程生命周期。
- SFTP 插件上传文件后,不会自动 ssh 连过去
kill -HUP服务,除非你硬编码进post_upload_command - 没有内置的
Remote Explorer视图,看不到远程正在运行的node或python进程 - 调试 Python/Node.js 必须靠本地调试器连接远程端口(如
ptvsd或node --inspect),Sublime 本身不提供调试适配层 - 多跳 SSH(ProxyJump)、
~/.ssh/config别名、StrictHostKeyChecking=no等高级 SSH 特性,SFTP 插件均不解析,得手动拼进host字段或预建隧道
真正需要“运行远程”的场景,该换什么工具?
如果你频繁需要在远程执行、调试、看日志、启停服务,Sublime 的能力边界已经到了——它只适合“编辑+同步”,不适合“开发+运行”闭环。
- VS Code + Remote-SSH:唯一成熟支持完整远程开发会话的主流编辑器,含终端、调试、扩展同步、端口转发
- JetBrains Gateway:适合 Java/Python 全家桶用户,远程运行体验接近本地 IDE
- 纯终端方案:用
tmux+vim+ssh组合,在远程直连环境下效率极高,且无同步延迟 - 别强行给 Sublime 加壳:有人用 AutoHotkey 或 AppleScript 封装“保存→上传→SSH执行”为快捷键,但一旦网络抖动或命令出错,状态就不可控
post_upload_command 调用 ssh,就得同时维护两套环境——本地的 Sublime 插件链 + 远程的部署脚本链。稍有不一致,就会出现“文件传上去了,但服务没重启”这种静默失败。











