sftp插件配remote_path+upload_on_save即可满足多数远程编辑需求，无需ssh隧道或rsub；remote_path须为绝对路径，upload_on_save需配合sync_down_on_open慎用，ignore应排除node_modules等目录，sftp-config.json修改后必须重启sublime text。
直接用 SFTP 插件配 remote_path + upload_on_save 就够用
绝大多数远程编辑需求，根本不需要折腾 SSH 隧道或 rsub。SFTP 插件走标准 SFTP 协议，稳定、可预测、支持断点续传，只要服务器开了 SSH（默认 22 端口），配置对了就能干活。
关键不是“能不能连”，而是remote_path写对没、upload_on_save开没开、本地路径和远程路径是否真能一一映射。
-
remote_path必须是绝对路径，~/project这种写法会失效——SFTP 插件不做 shell 展开，它会字面拼成/home/user/~/project -
upload_on_save设为true后，保存即上传；但若本地文件还没从服务器拉下来（比如首次打开），保存会上传一个空文件，建议配合sync_down_on_open使用（仅限单人维护场景） - 如果项目里混着
node_modules或.git，务必在ignore里加上，否则保存时可能卡住或报错 “Permission denied”
别信 subl user@host:/path 这种命令能工作
Sublime Text 的 subl 命令只认本地路径和 file:// URL，压根不解析 SSH URI。你敲 subl deploy@prod:/var/www/index.php，它要么静默失败，要么开个空白窗口——这不是插件问题，是 Sublime 内核限制。
所有所谓“SSH 远程编辑”，实际只有两条路：
- 用 SFTP 插件：文件先下到本地临时缓存，改完再上传，
upload_on_save控制时机 - 用 rsub：靠
ssh -R 52698:localhost:52698反向转发，远程执行rsub /path才能触发本地 Sublime 打开，且保存直接写回远程磁盘，upload_on_save完全无效
二者机制完全不同，不能混用。同一目录下既开 rsub 又启 SFTP 同步，大概率刚保存就被覆盖。
sftp-config.json 改完必须重启 Sublime Text
SFTP 插件不会热重载配置。你改完 sftp-config.json 里的 host、user 或 ssh_key_file，不重启 Sublime，它继续用旧配置连——连不上、报错、甚至连错机器，都可能是因为这个。
尤其注意 ssh_key_file 路径：写 ~/.ssh/id_rsa 不生效，得写成 /home/deploy/.ssh/id_rsa；私钥权限要是 600，否则连接时提示 “Permissions too open”。
首次连接还会弹窗让你确认主机指纹，这个不能跳过，否则后续所有操作都会卡在 “Connecting…”。
sync_down_on_open = true 是把双刃剑
设成 true 意味着你双击项目里任一文件，SFTP 插件会先去服务器下载最新版，再打开。听起来很省心，但有硬伤：
- 协作场景下危险：别人刚 push 了代码，你本地有未提交修改，
sync_down_on_open会直接覆盖你的本地副本，Git 都救不回来 - 大文件（如日志、压缩包）每次打开都强制下载，卡顿明显，还浪费带宽
- 如果远程文件被其他进程（比如 cron、nginx）实时写入，你打开瞬间的内容可能已经过期
更稳妥的做法是关掉它，需要同步时右键 → SFTP → Download File，手动控制时机。
