sublime text远程编辑自动同步有两种互斥机制：sftp插件通过upload_on_save实现本地→远程上传，remotesublime（rsub）则通过ssh反向端口转发直连远程文件并实时写回，二者混用会导致覆盖冲突或静默失败。
Sublime Text 远程编辑自动同步不是单一功能，而是两种互斥机制：SFTP 插件的本地→远程上传同步，和 RemoteSublime（rsub）的远程文件直连编辑。选错方案会导致保存失效、文件覆盖或静默失败。
SFTP 插件启用 upload_on_save 自动上传
这是最常用、也最容易配错的方式。它依赖本地文件修改后触发上传动作，不打开远程文件，而是把本地副本推上去。
-
upload_on_save必须设为true，且配置写在项目级的sftp-config.json里（不是全局设置） - 确保
remote_path和local_path映射正确——local_path是你当前 Sublime 打开的文件夹路径，不能是父目录或空字符串 - 如果用密码登录，
password字段要存在；但更推荐用ssh_key_file指向私钥路径，避免连接卡在认证环节 - 首次连接会弹出主机指纹确认框，必须点“是”，否则后续所有同步都静默失败
- 注意
ignore_regexes里别误写了sftp-config.json自身——它被忽略后插件就找不到配置，upload_on_save彻底不生效
RemoteSublime（rsub）下保存即写回远程，无 upload_on_save
很多人以为开了 upload_on_save 就能“对 rsub 打开的文件也起作用”，其实完全无效。rsub 的保存行为绕过 SFTP 插件全部逻辑，直接走 SSH 管道写回远程磁盘。
- 远程服务器必须已安装可执行的
rsub（常见路径：/usr/local/bin/rsub或~/bin/rsub），权限为755 - 本地 Sublime 必须启用
rsub插件（Preferences → Package Settings → rsub → Settings），端口默认52698，防火墙不能拦截 - SSH 连接必须带
-R 52698:localhost:52698参数，用~/.ssh/config配 alias 最稳妥，例如：Host myserver<br> HostName server.example.com<br> User deploy<br> RemoteForward 52698 localhost:52698
- 在远程终端执行
rsub /path/to/file，本地 Sublime 才会打开——subl user@host:/path这种写法一定失败，Sublime 不解析 SSH URI - 远程文件若被其他进程改过（比如
git pull），rsub 不会自动刷新，得手动关掉再重开
两个方案混用会丢文件
同一个项目里既用 rsub 编辑，又开着 SFTP 的 upload_on_save 或 sync_down_on_open，极大概率导致刚保存完就被 SFTP 覆盖掉。
- rsub 编辑时，SFTP 插件根本不知道这个文件正在被编辑，它只监听本地文件系统变化
- 如果你在 rsub 打开的文件里改了内容并保存，远程已更新；但此时 SFTP 可能正把旧的本地缓存（实际为空或过期）上传覆盖过去
- 没有“下载最新版”按钮，也没有冲突提示——只有静默覆盖，且时间戳可能还显示“刚刚修改”
- 权限变更也会暴露问题：比如远程
chmod 400后，rsub 仍能打开，但保存时抛Permission denied错误，而 SFTP 在同样权限下可能直接跳过上传
rsub 的延迟不是网络问题，而是 SSH 加密/解密 + TCP 往返叠加的结果，公网环境下每次保存可能有 200–800ms 延迟；SFTP 的上传耗时则取决于文件大小和带宽。选哪个，本质是在“实时写回远程”和“可控上传流程”之间做取舍——不能既要又要。
