SFTP插件上传大文件会超时或从头重传，因其底层OpenSSH sftp不支持断点续传，且受插件socket超时（约30秒）和SSH服务端ClientAliveInterval设置过短影响；真正可行方案是改用lftp等支持续传的工具集成到Sublime。
为什么 SFTP 插件上传大文件会超时或从头重传
SFTP 插件（wbond 版）底层调用的是 OpenSSH 的 sftp 命令，而 OpenSSH 的 sftp 客户端**不支持断点续传**——它没有实现 RFC 3659 的 SIZE 或 MD5 扩展，也没有记录传输偏移量。一旦连接中断（常见于 30 秒无数据、防火墙踢出、WiFi 切换），再次执行 put 就是全新上传，不是续传。
超时通常来自两层：一是插件自身默认的 socket 连接超时（约 30 秒），二是远程 SSH 服务端的 ClientAliveInterval 设置过短（如默认 0 或 120 秒），导致空闲连接被强制关闭。
- 插件不会主动探测断连，也不会重试；它只管发完一整块，失败就报错
-
upload_on_save对大文件无效：保存动作触发的是单次全量上传，不是分块或校验 - 即使你手动右键选 “Upload File”，底层仍是
put local_path remote_path，无偏移参数
如何绕过超时限制并让大文件“伪续传”成功
真正可行的方案不是靠插件本身，而是**改用支持断点续传的命令行工具 + Sublime 外部命令集成**。SFTP 插件只适合小文件实时同步，大文件必须换工具。
- 推荐用
lftp：它原生支持mirror -c（校验+续传）、reput、自动重试和超时控制 - Windows 下安装
lftp：通过choco install lftp或下载编译版，确保能运行lftp --version - 写一个批处理脚本（例如
upload_large.bat）：lftp -c " set net:max-retries 5 set net:timeout 60 set ftp:ssl-allow false open sftp://<user>:<pass>@<host>:22 cd "/path/on/server" lcd "C:/local/path" reput "large_file.zip" "
- 在 Sublime 中绑定该脚本为自定义命令（通过
Tools → Build System → New Build System），快捷键触发，避开插件限制
sftp-config.json 里哪些字段影响大文件稳定性
插件配置本身不能解决续传，但错误配置会让超时更频繁、连接更脆弱。以下字段必须严格检查：
-
"port"：必须显式写22（哪怕没改过），否则插件可能 fallback 到默认值并误判 -
"connect_timeout"：插件支持该字段（非官方文档但实际有效），设为120可缓解初始连接超时 -
"sync_down_on_open"和"sync_skip_deletes"：大文件场景下建议关掉，避免打开文件时触发全量比对拖慢响应 -
"ignore_regexes"：加上"\.zip$"或"large_.*\.tar\.gz$"，防止误触upload_on_save导致意外上传 -
"remote_path"结尾不要加/：否则插件可能把file.zip传成/path//file.zip，某些服务器拒绝解析双斜杠
密钥登录下大文件传输失败的隐蔽原因
即使 ssh user@host 能连上，SFTP 插件仍可能卡在上传阶段，尤其在大文件场景：
-
ssh_key_file路径含空格或中文：Windows 下必须用正斜杠C:/Users/Name/.ssh/id_rsa，反斜杠C:...会被 JSON 解析器截断 - 私钥格式不对：插件只认 OpenSSH 格式（
-----BEGIN OPENSSH PRIVATE KEY-----），PuTTY 的.ppk文件需用puttygen转成 OpenSSH 格式再保存 - 服务器
sshd_config缺少Subsystem sftp /usr/lib/openssh/sftp-server或启用了ForceCommand，会拦截大文件的open()请求 - 远程磁盘满或
ulimit -f限制了单文件大小：上传中途报Failure且无明确错误，要查服务端dmesg或/var/log/auth.log
真正的大文件上传，别指望 SFTP 插件扛住。它设计目标是开发同步，不是运维级文件传输。稳定性和可控性，永远优先交给 lftp、rsync over ssh 或 curl -T --retry 这类工具。插件配置只是让它“不拖后腿”，而不是“替你干活”。
