sublime text sftp远程编辑失败主因是远程权限链断裂：缺w/x权限、属主错误、strictmodes降级为只读、或preserve_modification_times在nfs/容器中静默终止；需逐级验证目录权限、属主、密钥格式及配置字段。
Sublime Text 远程编辑权限受限，90% 以上不是插件或配置写错了，而是远程路径的权限链断裂——缺 w（写）、x（执行/进入）权限，或 SSH 层因密钥权限不对被 StrictModes 降级为只读会话。它不报错，只“假成功”：日志显示 Upload completed，但远程文件内容完全没变。
远程目录不可写或不可进入导致静默失败
SFTP 插件上传不是覆盖文件，而是先创建临时文件、重命名、再删旧文件。整条路径上任一环节缺 w 或 x 权限都会卡住。
- 用终端登录服务器，逐级检查：
ls -ld /var/www/html→ 输出必须含drwxr-xr-x（至少有wx） - 实测写能力：
touch /var/www/html/.test && rm /var/www/html/.test→ 失败说明权限或 SELinux/AppArmor 拦截 - 父目录属主错误很常见：
ls -ld /var/www若是root:root，普通用户无法在其下建子目录；应运行：sudo chown -R $USER:www-data /var/www/html（Ubuntu）或sudo chown -R $USER:nginx /var/www/html（CentOS）
preserve_modification_times 在 NFS/容器中引发静默终止
这个字段默认为 true，在 NFS 挂载、Docker volume 或某些云存储后端上，时间戳同步失败会导致整个上传流程被协议层静默丢弃——你改了保存，远程文件就是不动。
- 直接在
sftp-config.json根层级加："preserve_modification_times": false - 它只影响时间戳，不影响文件内容同步，关掉后绝大多数容器/NFS 场景就能恢复上传
- 别和
default_permissions混淆："default_permissions": "644"是控制新建文件权限，和时间戳无关
SSH StrictModes 降级为只读会话却不提示
OpenSSH 默认开启 StrictModes on。只要 ~/.ssh/authorized_keys 权限不是 600 或属主不对，SSH 就会悄悄降级为密码认证——而 SFTP 插件没配 password 字段，结果就是只读连接，不报错也不上传。
- 检查命令：
ls -l ~/.ssh/authorized_keys→ 必须是-rw-------且属主为你当前用户 - 修复命令：
chmod 600 ~/.ssh/authorized_keys && chown $USER:$USER ~/.ssh/authorized_keys - 改完重启 SSH：
sudo systemctl restart sshd（Linux）
Windows 下密钥格式不兼容导致连接失败
Sublime 的 SFTP 插件在 Windows 上只认 PuTTY 格式（.ppk），原生 OpenSSH 私钥（id_rsa）直接填进去无效，连接会卡在认证阶段。
- 用 PuTTYgen 打开你的
id_rsa（不是id_rsa.pub），点击Save private key生成id_rsa.ppk - 在
sftp-config.json中写："ssh_key_file": "C:/path/to/id_rsa.ppk"（注意用正斜杠或双反斜杠） - 别漏掉
"type": "sftp"—— 写成"ftp"或漏掉，插件会 fallback 到本地文件系统，看似保存成功，实则根本没传
最容易被忽略的是：SFTP 写入依赖整条路径可写可进，而不仅仅是目标文件所在目录；preserve_modification_times 关闭与否，在容器/NFS 环境里是“有没有上传”的分水岭；还有 Windows 用户常以为私钥通用，结果密钥根本没加载——这些点不逐个验证，光调配置毫无意义。
