sublime text 原生不支持 ftp/sftp 同步，依赖的第三方插件大多已停止维护或与 st4 不兼容；推荐使用 rsync + 本地编辑解耦方案，或 git-based synced 插件。
Sublime Text 本身不支持 FTP / SFTP 同步
直接说结论：Sublime Text 原生没有 FTP、SFTP 或远程文件同步功能。你看到的“Sublime FTP 插件”基本都是第三方开发的，且绝大多数已停止维护或与新版 Sublime（尤其是 Sublime Text 4）不兼容。
常见错误现象包括：SFTP 插件安装后无法启动、右键菜单无 Sync Remote、保存时提示 Connection refused 或直接卡死；更隐蔽的问题是，插件悄悄把文件传到错误路径，或覆盖了服务器上的修改却没提示。
真实使用场景里，这类插件只适合极简需求——比如偶尔编辑单个配置文件，且服务器允许密码登录、无双因素认证、防火墙放行了对应端口。
- 别指望它做团队协作级的双向同步（比如本地改了 A 文件、同事在服务器改了 B 文件，插件不会帮你 merge）
-
SFTP插件依赖 Python 2.7 运行时，而 Sublime Text 4 默认用 Python 3.8+，很多老插件会静默失效 - 如果你的服务器只开放 SFTP（非 FTP），但插件配置里误填了
ftp://协议，连接必然失败
靠谱替代方案：用 Rsync + 本地终端 + Sublime 打开
这不是“退而求其次”，而是更稳定、可审计、易调试的做法。核心逻辑是：文件同步交给专业工具（rsync），编辑留在 Sublime，两者解耦。
典型流程：你在本地有个项目目录，通过 rsync 把变更推到服务器指定路径，然后用 Sublime 直接打开本地副本——所有编辑操作都在本地完成，避免网络延迟和锁文件问题。
- 最简命令示例：
rsync -avz --delete ./user@server:/var/www/html/（注意末尾斜杠含义不同） - 加
--dry-run先看会同步哪些文件，避免误删 - 用
inotifywait（Linux/macOS）或fswatch可实现保存即自动同步，但要小心循环触发（比如同步完又触发本地保存事件） - Windows 用户可用
WinSCP配合“编辑→关联编辑器”指向subl，它会在本地缓存临时文件，编辑完再回传——本质仍是本地编辑 + 显式上传
如果非要插件方案：只考虑 Synced（Sublime Text 4 原生兼容）
目前唯一持续更新、明确支持 Sublime Text 4 的同步类插件是 Synced，但它不是 FTP/SFTP 客户端，而是基于 Git 工作流的轻量同步工具。
适用前提很具体：你的服务器和本地都装了 Git，且能通过 SSH 访问仓库；你接受“每次同步 = git push + git pull”，而不是实时文件搬运。
- 配置关键项是
remote_url（如ssh://user@server//home/user/site.git），注意双斜杠 - 它不会处理二进制文件冲突，遇到
.png被两人同时改，就真冲突了 - 性能影响：首次同步要完整 clone，后续靠 git diff 判断变更，比纯 rsync 略重，但比老式 FTP 插件可靠得多
- 不支持 FTP 协议，也不支持密码交互式登录——必须配好 SSH key
容易被忽略的权限和路径陷阱
哪怕工具链跑通了，90% 的“同步失败”其实出在服务端细节上，而不是 Sublime 设置。
- 服务器目标路径的属主和权限必须允许你的用户写入，
rsync不会自动chown；常见错误是传上去文件属主变成root，导致 Web 服务读不了 -
~在rsync或插件配置里可能不展开，务必写绝对路径，比如/home/deploy/app/而非~/app/ - Sublime 的
subl命令行工具默认不在系统 PATH 里（尤其 macOS 新版），终端调用前先运行ln -s "/Applications/Sublime Text.app/Contents/SharedSupport/bin/subl" /usr/local/bin/subl - 编辑远程日志文件（如
/var/log/nginx/access.log）时，别直接同步——这些文件通常由服务进程独占写入，强行覆盖会导致日志截断或权限错乱
真正麻烦的从来不是“怎么连上”，而是连上之后，谁在什么时候、以什么权限、改了哪一行——这些得靠工具链各司其职，而不是塞进一个插件里假装全自动。
