Sublime Text 3 SFTP插件保存失败：根源排查与根治指南
遇到Sublime Text 3的SFTP插件保存失败？先别急着重装插件。绝大多数情况下，问题根源并非插件本身，而是它在尝试写入远程服务器时被“拒之门外”——无论是显眼的“Permission denied”还是悄无声息的失败，最终都指向SSH权限、远程路径所有权或那些容易被忽略的SFTP配置细节。
SFTP保存失败根源在远程权限、路径或配置：remote_path错误、远程目录缺w/x权限、SSH StrictModes导致降级只读、upload_on_sa ve未匹配路径映射，或preserve_modification_times在NFS/容器中需设为false。
为什么SFTP保存后文件没更新，也不报错？
这大概是SFTP插件最令人困惑的“假成功”现象了：编辑器明明提示“Upload completed”，但远程服务器的文件内容却纹丝未动。问题通常出在以下几个环节：
remote_path配置偏差：路径拼写错误或少了一个/，都可能导致文件被上传到一个你完全没想到的目录。- 远程目录权限不足：上传文件不仅需要
w（写）权限，还需要x（执行/进入）权限。因为SFTP上传过程往往涉及创建临时目录或重命名操作，缺了x权限，流程就会卡住。 - SSH的
StrictModes限制：OpenSSH默认开启此选项。如果你的~/.ssh/authorized_keys文件权限是644或属主不对，SSH连接可能会降级为密码认证，导致SFTP会话静默回退到只读模式。 upload_on_sa ve的陷阱：在sftp_config.json中开启了"upload_on_sa ve": true，却没有设置"sync_down_on_open": false。这可能导致本地修改自动上传时，因远程文件被其他进程（如nginx、pm2）锁定而失败，且没有任何提示。
检查远程目录权限和属主的实操步骤
排查时，眼光不能只盯着目标文件。SFTP保存依赖于从根目录到目标文件的整条路径都具备可写和可进入的权限。可以按以下步骤操作：
- 查看目录权限：通过终端登录服务器，执行
ls -ld /var/www/html。如果输出是dr-xr-xr-x，说明目录不可写；drwxr-xr-x才是合格状态。 - 验证用户写权限：运行
touch /var/www/html/test.tmp && rm /var/www/html/test.tmp。如果失败，除了权限问题，还要考虑SELinux（Linux）或AppArmor等安全模块的拦截。 - 检查父目录属主：执行
ls -ld /var/www。如果属主是root:root，普通用户将无法在其中创建子目录。通常的解决方法是：在Ubuntu/Debian上使用sudo chown -R $USER:www-data /var/www/html，在CentOS上使用sudo chown -R $USER:nginx /var/www/html。 - 慎用
chmod 777：这虽然能快速解决问题，但会让Web目录完全可写，是许多CMS（如WordPress）被入侵的常见起点，应尽量避免。
SFTP配置里最容易踩坑的三个字段
sftp_config.json文件看似简单，但以下三个字段一旦配置有误，就足以让整个保存行为失控：
"type": "sftp"：这个字段必须明确指定，不能遗漏或留空。如果误写成"ftp"，插件会回退到本地文件系统操作，造成“保存成功”的假象，实际上文件根本没有传输。"sa ve_before_upload": true：这是默认值，建议保持开启。如果关闭此选项，又没有手动按Ctrl+S保存，直接使用快捷键上传，那么传输的将是旧的、未保存的本地内容。"preserve_modification_times": false：当远程路径位于NFS或某些容器挂载的卷上时，必须将此选项设为false。否则，上传后可能因时间戳同步失败，导致插件静默回滚整个操作。
用sshfs临时替代SFTP调试更直观
当SFTP插件的行为难以捉摸时，不妨绕过它，用更直接的方式连接服务器，这往往能更快定位问题：
- 挂载远程目录：在macOS/Linux上，运行
sshfs user@host:/var/www/html ~/mnt/remote -o follow_symlinks，然后将Sublime Text的工作区直接切换到~/mnt/remote目录。 - 直接观察错误：此时的文件保存操作等同于本地写入，任何权限问题（如
Operation not permitted）都会立刻触发系统级的明确报错，远比SFTP插件的静默失败更容易排查。 - 反推配置：调试成功后，可以对比
sshfs命令所使用的挂载参数（如-o allow_other、-o uid=501），来反推你的SFTP配置中可能缺少了什么关键设置。
说到底，真正的难点不在于让SFTP“能上传”，而在于让它“传得稳、改得准、错得明”。许多团队后期放弃SFTP插件，并非因为其功能薄弱，而是因为相关配置项分散在SSH层、文件系统层和Web服务层这三个地方，只要漏查其中一层，调试就可能前功尽弃。从长远来看，一种更省事的策略或许是：将开发服务器的/var/www目录权限设置为对应用户可写，然后结合rsync --delete和git hook进行同步。这种方式，有时反而比依赖实时SFTP上传更加稳定可靠。
