SFTP插件上传慢不是Sublime Text本身的问题，因其不处理网络传输，所有同步依赖插件底层的pysftp/paramiko实现，该实现默认启用加密压缩、小缓冲区（32768）、单连接串行传输，导致频繁保存小文件时响应迟缓。
为什么SFTP插件上传慢不是Sublime Text本身的问题
Sublime Text 本身不处理网络传输，所有远程同步都依赖 SFTP 插件的底层实现。它用的是 Python 的 pysftp（基于 paramiko），而这两个库默认启用加密压缩、小缓冲区、单连接串行传输——这对交互式编辑很友好，但对频繁保存的小文件（如 HTML/CSS/JS）反而拖慢响应。你看到的“保存后卡顿2秒”“右键 Browse Server 卡住”，基本都源于这个链路。
sftp-config.json 中必须调优的 4 个参数
在项目根目录下的 sftp-config.json 文件里，仅改这 4 项就能明显提速：
-
"transfer_buffer_size": 32768→ 改为131072（128KB），避免小包频繁握手 -
"concurrent_connections": 1→ 改为3，允许多文件并行上传（注意：服务器MaxStartups需 ≥3） -
"connect_timeout": 30→ 保持或略降为15，防止卡死在失败连接上 -
"ssh_host_keys": []→ 显式设为空数组，跳过已知主机验证（仅限可信内网环境）
别碰 "preserve_timestamps" 或 "sync_down_on_open"——前者会额外触发两次 stat 调用，后者在打开大文件时可能拉取整目录，反而更慢。
真正影响编辑流畅度的其实是本地缓存策略
SFTP 插件默认每次保存都走完整 upload 流程，不校验内容是否真有变更。如果你只是改了一行 JS，它仍会把整个文件重传一遍。解决办法有两个：
- 关闭
"upload_on_save": true，改用快捷键Ctrl+Alt+U（Windows/Linux）或Cmd+Alt+U（macOS）手动触发上传，只在确认修改后才传 - 配合
rsync做增量同步：在终端跑rsync -avz --delete --exclude="*.log" ./ user@host:/path/to/remote/，比 SFTP 插件快 3–5 倍，且能跳过未变文件
注意：rsync 方案需服务器开启 rsync 服务或使用 rsync over ssh，且不能替代实时编辑反馈——它适合批量发布，不是日常保存替代品。
哪些操作会悄悄拖慢你的远程编辑体验
这些看似无害的动作，实际会让 SFTP 插件反复建立连接或阻塞主线程：
- 在侧边栏右键点击远程目录 → 触发
ls -la全量扫描，尤其当目录含上千文件时必卡 - 开启
"sync_down_on_open": true后双击一个 PHP 文件 → 它先下载文件，再检查本地是否有同名未保存副本，最后才打开，三步全阻塞 - 配置里写了
"password": "xxx"→ 每次连接都做密码解密 + Base64 处理，不如直接用"ssh_key_file": "~/.ssh/id_rsa" - 在非项目根目录下打开单个远程文件（比如直接通过
Browse Server打开）→ 插件无法复用已有连接池，每次都新建 SSH 会话
最稳的用法是：始终以项目为单位打开（File > Open Folder），禁用自动同步，用密钥登录，上传靠快捷键或外部 rsync —— 这样才能把延迟压到 300ms 内。
