真正支撑“一键发布”的插件只有SFTP和SublimeBuild构建系统：SFTP负责文件同步（需配置sync_down_on_open、connect_timeout等关键参数），SublimeBuild通过自定义.sublime-build执行rsync+ssh等可控部署命令，二者组合实现稳定可维护的自动化流程。
哪些插件真正支撑“一键发布”流程
Sublime Text 本身不带部署能力，所谓“快速部署”全靠插件组合实现。真正高频、稳定、可维护的只有两个核心包：SFTP 和 SublimeBuild 自定义构建系统。其他如 Sync Settings 或 GitGutter 属于辅助工具，不能替代传输或执行逻辑。
常见错误现象：装了 FTPSync 或 RemoteSync 后发现无法保存即同步、配置项模糊、SSH密钥不生效——本质是这些插件已停止维护或依赖过时的 Python runtime。
-
SFTP支持 SFTP/FTP/FTPS，配置写在SFTP.sublime-settings文件里，支持 on_save 自动上传、双向同步、忽略路径（"exclude_patterns"）、私钥路径直填（"ssh_key_file"） - 自定义
.sublime-build文件更适合 rsync + ssh 场景，比如部署到 VPS 或容器内，命令行可控、日志可捕获、失败能返回 exit code - 别装
Deployer类插件——它们多数硬编码 FTP 账号密码，明文存本地，且不支持现代 SSH key 认证
SFTP 配置最容易漏掉的三项关键参数
很多人配完 SFTP 插件后测试上传失败，不是账号错，而是漏掉了底层协议细节。尤其在 macOS 或 Linux 上连接 OpenSSH 服务时，以下三项必须显式声明：
-
"sync_down_on_open": false—— 默认为 true，一打开文件就拉远程版本，容易覆盖本地未提交修改 -
"connect_timeout": 30—— 默认 5 秒，高延迟网络（如跨国服务器）下直接超时中断 -
"preserve_modification_times": true—— 否则上传后远程文件 mtime 变成当前时间，影响基于时间戳的构建脚本（如 Makefile）
另外，"remote_path" 必须以 / 开头（如 "/var/www/html"），相对路径（如 "html"）会被解释为用户 home 下子目录，极易传错位置。
用 .sublime-build 实现 rsync 部署时的权限与路径陷阱
rsync 方案比 SFTP 更灵活，但 .sublime-build 文件里几个细节不处理好，就会卡在 permission denied 或 no such file。
- Windows 用户注意：
shell_cmd里不要用rsync命令——默认没装；改用bash -c "rsync ..."并确保 Git for Windows 的 bin 目录在 PATH 中 - macOS/Linux 用户要加
"path": "/usr/local/bin:/opt/homebrew/bin"，否则找不到 Homebrew 安装的 rsync -
"file_regex"别省略，否则 rsync 报错（如Permission denied (publickey)）不会高亮显示，只在小字控制台一闪而过 - 避免在
shell_cmd中拼接变量如$project_path—— Sublime 不解析 shell 变量；改用${project_path}（双大括号），这是 Sublime 的变量语法
为什么别把部署逻辑塞进插件快捷键
有人给 SFTP 绑定 Ctrl+Alt+U，再给 Build 绑定 Ctrl+Alt+D，以为这就是“一键”。实际协作中这会出问题：
- 不同成员的服务器地址、密钥路径、忽略规则不同，但快捷键触发的是同一套配置，无法按项目切换
- 没有中间确认环节——误操作 Ctrl+Alt+U 上传 dev 环境代码到 prod 目录，不可逆
- 无法做前置检查（如 git status 是否干净、package.json 版本是否更新），纯机械动作风险高
真正可持续的做法是：每个项目根目录放一个 deploy.sublime-build，里面写明目标环境、校验步骤、回滚指令。用 Ctrl+Shift+P → Build With… 手动选，反而更安全、更可追溯。
