Sublime Text 本身不支持原生远程编辑，可靠方案只有两种：一是用 sshfs 挂载远程目录为本地路径（macOS/Linux 用 sshfs，Windows 用 SSHFS-Win），实现原子保存与完整插件支持；二是用 SFTP 插件做“下载-编辑-上传”，但存在同步冲突、无失败提示、功能受限等问题，仅适合小文件或备用场景。
Sublime Text 本身不支持直接远程编辑（比如像 VS Code 的 Remote-SSH 那样原生挂载远程文件系统），想“同步远程编辑”，本质只有两种可行路径：本地映射远程路径，或借助插件在本地与远程间自动同步。强行用 FTP 插件实时编辑容易丢文件、冲突、无原子写入保障——这不是推荐做法。
用 sshfs 挂载远程目录到本地（macOS / Linux）
这是最接近“真实编辑体验”的方案：远程目录变成你本地的一个文件夹，Sublime Text 打开它就跟打开本地项目一样，保存即生效，无同步延迟，支持所有插件（如 GitGutter、LSP）。
-
sshfs必须在本地安装（macOS 用brew install sshfs，Ubuntu 用sudo apt install sshfs） - 确保远程服务器已启用
AllowTcpForwarding yes和PermitTunnel yes（通常默认开启） - 挂载命令示例：
sshfs user@host:/path/to/project ~/mnt/remote-proj -o follow_symlinks -o reconnect -o ServerAliveInterval=15；其中-o follow_symlinks很关键，否则符号链接会显示为乱码 - 挂载后若提示
Connection reset by peer，大概率是远程 SSH 服务端超时断连，加-o ServerAliveInterval=15可缓解 - 卸载用
umount ~/mnt/remote-proj（macOS）或fusermount -u ~/mnt/remote-proj（Linux）
Windows 下用 WinFsp + SSHFS-Win 实现等效挂载
Windows 原生不支持 FUSE，但 SSHFS-Win（基于 WinFsp）能提供类似体验，挂载后显示为网络驱动器（如 Z:\），Sublime Text 可直接打开该盘符下的文件。
- 必须按顺序安装：先装
WinFsp，再装SSHFS-Win，否则挂载失败且无明确报错 - 连接配置中，“Remote directory” 填绝对路径（如
/home/user/app），开头的/不能省；“Mount point” 推荐选空文件夹（如Z:\project），而非直接选Z: - 若 Sublime Text 提示 “Permission denied” 或无法保存，检查远程目标目录权限是否允许你的用户写入（
ls -ld /home/user/app），Windows 端无需额外设置文件属性 - 挂载后资源管理器能正常浏览，但某些 Sublime 插件（如
SideBarEnhancements的右键菜单）可能因路径格式异常失效——这不是 bug，是 Windows 对 UNC 路径兼容性限制
避免使用 SFTP 插件做日常编辑
虽然 SFTP 插件（由 wbond 维护）长期被误当作“远程编辑方案”，但它实际是“下载 → 编辑 → 上传”三步模型，不具备一致性保障，尤其在多人协作或大文件场景下风险突出。
- 保存时若网络抖动，可能出现“本地已保存但远程上传失败”，导致状态不一致；插件不会回滚本地文件，也不会提示失败（除非你打开控制台）
- 不支持部分 Sublime 核心功能：比如
Find in Files无法跨远程目录搜索；Build System中调用的本地脚本无法引用远程路径 - 如果仍要用，务必关闭
"upload_on_save": true，改用手动触发Upload File（快捷键Ctrl+Alt+U），并在配置里加上"keep_remote_time": true，减少时间戳干扰 - 它的合理定位是：一次性部署、小配置文件修改、无其他挂载条件时的备用手段，不是开发主力流程
真正稳定的远程编辑，核心在于让远程路径“变成本地路径”。挂载方案看似多一步操作，但换来的是原子保存、完整 IDE 功能支持和可预测的行为。最容易被忽略的一点：挂载后记得在 Sublime Text 中用 Project → Save Project As… 保存工作区，否则重启后需重新挂载再手动打开——这不是 Sublime 的问题，而是路径来源变了。
