SFTP插件默认不自动上传，需在sftp-config.json中设置"upload_on_save": true；检查remote_path权限、SSH认证方式；禁用atomic_save可解决本地保存失败导致的同步问题；ignore_regexes会静默跳过匹配文件的上传。
保存后远程文件没更新？先确认 upload_on_save 是否启用
默认情况下，SFTP 插件不会自动上传——你编辑完按 Ctrl+S，只是保存了本地副本，远程服务器上的文件纹丝不动。这不是 bug，是插件的默认保守策略。
必须在项目根目录下的 sftp-config.json 中显式开启：
{
"upload_on_save": true,
"host": "192.168.1.100",
"user": "deploy",
"remote_path": "/var/www/myapp/"
}
注意：upload_on_save 是布尔值，不是字符串，别写成 "upload_on_save": "true"；它只对当前配置生效，不跨项目继承。
保存卡住或报错 “Permission denied”？检查 remote_path 权限和 SSH 认证方式
Sublime 通过 SFTP 写入远程文件，本质是用你的 user 账户在远程执行 open() + write()。哪怕连接成功，仍可能因权限不足失败。
- Linux/macOS 远程服务器：运行
ls -ld /var/www/myapp/，确认输出中第三段（用户权限位）含w，且你的user是该目录所有者或所属组成员 - Windows 远程 IIS 或 SMB 共享：确保共享权限和 NTFS 权限都允许该用户“修改”
- 避免密码明文：把
"password": "xxx"换成"ssh_key_file": "~/.ssh/id_rsa"，既安全又绕过密码输入阻塞
文件改了但远程没变？atomic_save 在本地作祟
你可能没意识到：Sublime 本地保存时默认启用 atomic_save。它先写 file.tmp，再 rename 替换原文件。而 SFTP 插件同步的是最终保存的文件——如果本地 atomic_save 失败（比如 OneDrive 同步目录、WSL2 的 /mnt/c/），你看到的“已保存”其实是假象，SFTP 根本没收到有效变更。
验证方法：打开 Sublime 控制台（Ctrl+`），执行 view.is_dirty()，返回 True 就说明本地根本没真正保存成功。
临时解法：在 Sublime 用户设置里加一行：
"atomic_save": false
这样 Sublime 直接覆写原文件，SFTP 才能捕获到真实变更。
同步延迟或漏文件？ignore_regexes 和 upload_on_save 的组合陷阱
upload_on_save 不会跳过被 ignore_regexes 匹配的文件，但它会影响“是否触发上传流程”。例如你配置了：
"ignore_regexes": [".git", "node_modules"], "upload_on_save": true
这时编辑 src/index.js 会上传，但编辑 .git/config 不会——这正常；可如果你误把 index.js 加进了 ignore 列表，保存就彻底静默失效，连错误提示都没有。
更隐蔽的问题：某些构建产物（如 dist/*.js）被忽略后，即使你手动右键 Upload File，SFTP 插件也会跳过——它的 ignore 规则作用于所有上传路径，不只是自动保存。
建议：首次配置时先清空 ignore_regexes，确认基础同步通了，再逐步加规则。
真正容易被忽略的是：SFTP 插件的 upload_on_save 只监听“文件内容变更”，不监听文件名、权限、时间戳等元数据变化。如果你只是重命名远程文件或改 chmod，Sublime 完全感知不到，也不会触发同步。
