sublime本身不支持一键部署，真正起作用的是构建系统调用rsync等命令行工具或sftp插件配置；需ssh免密登录、正确设置working_dir与ignore_regexes，并在脚本中加入校验与回滚逻辑保障安全。
Sublime 本身不执行部署，真正起作用的是你配置的命令行工具链；所谓“一键”，本质是 Sublime 触发一个本地 shell 脚本或 rsync/ssh 命令。
用构建系统（.sublime-build）调用 rsync 或 scp
Sublime 的构建系统是绕过插件、直接对接命令行最干净的方式。它不依赖 SFTP 插件状态，也不受 GUI 同步逻辑干扰，适合需要校验、打包、重启服务的完整流程。
-
rsync比scp更可靠：支持增量同步、排除规则（--exclude=".git"）、权限保留（-p）和删除远端多余文件（--delete） - 必须提前配置好 SSH 免密登录，否则构建会卡在密码提示；验证方式：
ssh -o ConnectTimeout=3 user@host exit -
working_dir必须设为项目根目录，否则${file_path}等变量解析会出错 - Windows 用户注意：若用 Git Bash，
shell设为true；若用 WSL，则需确保路径映射正确（如/mnt/c/Users/xxx/project）
示例 deploy-prod.sublime-build：
{
"cmd": ["rsync", "-avz", "--delete", "--exclude=.git", "--exclude=node_modules", "${project_path}/", "user@prod-server:/var/www/myapp/"],
"working_dir": "${project_path}",
"shell": true,
"encoding": "utf-8"
}
SFTP 插件上传失败常见原因
SFTP 插件看似简单，但实际同步失败往往不是配置问题，而是权限或状态误判导致的静默失败。
- 上传后文件时间戳没变？检查服务器端磁盘是否只读，或
umask导致新建文件无写权限 -
upload_on_save不生效？确认当前文件已保存（未 dirty），且sftp-config.json中该字段为布尔值true，不是字符串"true" - 右键 “Upload File” 灰掉？说明 SFTP 插件未识别当前文件夹为已配置项目——必须在项目根目录下打开文件，或手动执行
SFTP: Map to Remote - 忽略规则失效？
ignore_regexes是正则，不是 glob；要忽略dist/下所有内容，得写"dist/.*"，不是"dist/"
部署脚本里必须加的三道保险
直接在构建系统里写长命令容易失控。更稳妥的做法是把逻辑收进 shell 脚本，Sublime 只负责调用它。这类脚本最容易被跳过的其实是安全边界。
- 远程执行前先
ssh user@host 'ls /var/www/myapp/healthz'，确认服务端基础环境就绪 - 同步完成后加
ssh user@host 'cd /var/www/myapp && git rev-parse HEAD 2>/dev/null || echo "no git repo"'，避免误覆盖非 Git 管理的目录 - 重启服务前，用
timeout 5 curl -f http://localhost:3000/healthz检查新代码是否能响应，失败则不重启，保留旧版本
这些检查在本地脚本里写死比在 .sublime-build 里拼接命令可读性强得多，也方便单独测试。
真正难的不是让 Sublime “按一下就传上去”，而是传完之后系统是否还活着、数据是否一致、回滚路径是否可用。SFTP 插件解决传输，构建系统解决触发，而脚本里的校验逻辑，才是自动化部署不变成“自动翻车”的关键。
