sftp上传静默失败主因是远程目录缺w/x权限、ssh strictmodes降级只读、preserve_modification_times在nfs/容器中设为true，或upload_on_save未匹配路径映射规则。
remote_path目录缺w/x权限导致静默失败
你看到“Upload completed”但远程文件没变，大概率是远程目录不可写或不可进入。SFTP上传不是简单覆盖文件，它要先创建临时文件、重命名、删旧文件，每一步都依赖目录的w（写）和x（执行/进入）权限。
- 用终端登录服务器，运行
ls -ld /var/www/html：如果输出是dr-xr-xr-x，说明目录不可写；必须是drwxr-xr-x或更宽松（但别用777） - 实测写权限：
touch /var/www/html/test.tmp && rm /var/www/html/test.tmp，失败就不是插件问题，而是系统级拦截（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）
SSH StrictModes开启引发只读降级
服务器/etc/ssh/sshd_config里StrictModes on（OpenSSH默认）时，只要~/.ssh/authorized_keys权限不是600，或属主不对，SSH连接就会悄悄降级为密码认证——而SFTP插件没配password字段，结果就是静默只读，不报错也不上传。
- 确认密钥文件权限：
ls -l ~/.ssh/authorized_keys，必须是-rw-------且属主为你当前用户 - 修复命令：
chmod 600 ~/.ssh/authorized_keys && chown $USER:$USER ~/.ssh/authorized_keys - 改完重启sshd：
sudo systemctl restart sshd（Linux）或sudo service ssh restart
sftp-config.json里preserve_modification_times设错
在NFS挂载、Docker容器卷或某些云存储后端上，preserve_modification_times: true（默认）会导致上传后时间戳同步失败，进而触发SFTP协议层拒绝写入——表现就是文件内容没更新，日志里可能有Failure但无具体错误。
- 直接在
sftp-config.json根层级加一行："preserve_modification_times": false - 这个开关只影响文件时间戳，不影响内容同步，关掉后绝大多数NFS/容器场景就能正常上传
- 别和
default_permissions混淆：default_permissions控制新建文件权限（如"644"），和时间戳无关
upload_on_save生效但被路径映射规则过滤
upload_on_save: true不是全局开关，它只对“当前文件路径匹配remote_path映射规则”的文件生效。你改了/src/js/app.js，但remote_path设的是"/var/www/html/"，那它根本不会触发上传——插件连试都不试。
- 确保本地项目根目录结构和远程路径对齐，比如远程是
/var/www/html/js/app.js，本地就得是html/js/app.js - 或者用
file_regex显式声明匹配规则，例如："file_regex": "^(src|js|css)/.*\.(js|css|html)$" - 检查是否误启
sync_down_on_open: true：它会在打开文件时从远程拉取，覆盖本地未保存修改，造成“改了又变回去”的假象
x权限和StrictModes连锁反应——它们不报错，只沉默拒绝。先跑一遍touch + rm测试，再查authorized_keys权限，比反复调配置快得多。
