Sublime Text + SFTP 远程直编：零感知修改服务器与容器文件

1. 项目概述：为什么在 Sublime Text 里直连服务器改文件，比来回拖拽、反复上传强十倍

你有没有过这样的时刻：改一行 CSS，要保存本地 → 切到终端 →scp传上去 →ssh进去确认路径 →vim打开再检查 → 发现漏了个分号，又得重来一遍？或者更糟——在 Docker 容器里调试 Node.js 应用，每次改个路由逻辑，就得docker cp进容器、docker exec -it进去验证、改错再重来……整个流程像在手动拧螺丝，效率低、易出错、还特别打断思路。这根本不是开发，是体力活。

我做后端和 DevOps 十多年，带过二十多个项目，从 PHP 小站到 Kubernetes 上跑的微服务集群，凡是需要频繁修改远程配置、日志模板、Nginx 规则、Dockerfile 或容器内脚本的场景，SFTP 插件 + Sublime Text 的组合，就是我团队默认的“最小可行编辑链”。它不依赖 IDE 的重型生态，不强制你学新快捷键，也不要求你把整个项目 clone 到本地——你看到的就是服务器上真实的文件树，双击即开，Ctrl+S 即存，保存瞬间就写进/var/www/html/index.php或/app/src/utils.js，连chmod都能自动同步。这不是“远程编辑”，这是把 Sublime Text 变成你服务器的原生编辑器外壳。

核心关键词已经非常清晰：Sublime Text、SFTP、远程文件管理、Docker 容器文件修改、服务器配置同步。这个方案真正解决的，不是“能不能连上”的问题，而是“如何让编辑行为零感知地发生在目标环境”——你改的不是副本，就是本体；你保存的不是草稿，就是生效代码。它适合三类人：运维工程师要批量改 Nginx 配置、全栈开发者要调试容器内 Python 脚本、前端同学要实时调整部署在测试机上的 Vue 构建产物。不需要你会写插件，不需要你配 SSH 密钥对（虽然推荐），甚至不用重启 Sublime——装好就能用，5 分钟内完成从本地编辑器到生产环境文件系统的无缝缝合。

2. 整体设计思路与方案选型：为什么是 SFTP，而不是 FTP/SMB/VS Code Remote？

很多人第一反应是：“VS Code 不是有 Remote-SSH 吗？”“PyCharm 不是自带 Deployment 吗？”——没错，它们都能连，但设计目标完全不同。VS Code Remote 是把整个开发环境搬过去，它启动的是远程的 VS Code Server，你本地只是个轻量客户端；PyCharm Deployment 是单向同步，改完要手动“Upload to…”；而SFTP for Sublime Text 的本质，是“文件系统级映射”。它不启动任何远程进程，不占用容器内存，不监听额外端口，只用标准的 OpenSSH 协议（默认 22 端口），所有操作都走 SFTP 子协议，和sftp user@host命令行完全一致。这意味着：你在容器里跑一个只有 10MB 内存的 Alpine Linux，只要sshd在跑，它就能连；你在一台被严格限制出站的堡垒机上，只要能ssh过去，它就能连；你用的是老旧的 CentOS 6，只要 OpenSSH 5.3+（2009 年版本），它照样连。

我们对比下主流方案的核心差异：

你看，SFTP 插件胜在“无感”——它不改变你的工作流，只增强它。你不需要为每个项目开一个 Remote-SSH 窗口，不需要记住 Deployment 的 mapping 路径规则，更不用写inotifywait -m -e modify /local/path | while read ...这种容易出错的管道命令。它就是 Sublime Text 的一个“透明图层”：你打开的sftp://user@192.168.1.100:/etc/nginx/conf.d/，在 Sublime 里显示的图标、右键菜单、搜索框，和你打开C:\project\完全一样。这种一致性，是其他方案刻意牺牲掉的体验。

还有一个关键点常被忽略：权限继承与上下文感知。当你用scp或rsync上传文件，目标文件的 owner/group 往往变成 root 或 daemon，导致 Web 服务读取失败；而 SFTP 插件在保存时，会自动以你登录的用户身份执行open()和write()，文件 owner 就是你指定的user，group 也保持一致。更重要的是，它能识别.gitignore、.env等敏感文件，并默认禁止上传（可配置），避免你手滑把数据库密码传到线上目录。这些细节，不是功能列表里的小字，而是每天帮你省下三次chown -R www-data:www-data /var/www的真实价值。

3. 核心细节解析与实操要点：SFTP 插件的安装、配置与安全边界

SFTP 插件本身由 wbond 开发，GitHub 仓库叫sublimetext-sftp，目前稳定版是 v3.14.2（截至 2024 年中）。它不是 Sublime Text 官方插件，但社区维护极好，更新频率高，文档详尽。安装方式有两种，我强烈推荐第一种——因为它能自动处理依赖和更新：

3.1 安装方式：Package Control 是唯一正解

1. 如果你还没装 Package Control（Sublime Text 的包管理器），先按Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS）打开命令面板；
2. 输入Install Package Control，回车执行（它会自动下载并重启 Sublime）；
3. 重启后再次Ctrl+Shift+P，输入Package Control: Install Package，回车；
4. 在弹出的搜索框里输入SFTP，选择第一个SFTP（作者 wbond），回车安装。

提示：不要从 GitHub 下载 zip 手动解压！手动安装会导致无法自动更新，且容易因 Python 版本不匹配（Sublime Text 3 用 Python 3.3，Sublime Text 4 用 Python 3.8）引发插件崩溃。Package Control 会根据你的 Sublime 版本自动分发对应二进制包。

安装完成后，你不会看到新菜单——这是对的。SFTP 插件是“按需激活”的：只有当你右键某个文件夹、或通过命令面板调用时，它才加载。这种懒加载机制，让 Sublime 启动速度不受影响，也避免了后台常驻连接消耗资源。

3.2 配置文件结构：一个 JSON 文件，控制全部行为

SFTP 的核心是sftp-config.json配置文件。它必须放在你准备映射的本地文件夹根目录下（注意：不是 Sublime 安装目录，也不是插件目录）。例如，你想编辑服务器/var/www/myapp，就在你本地新建一个空文件夹myapp-remote，然后在这个文件夹里创建sftp-config.json。这个设计很妙：它让每个项目拥有独立的连接上下文，切换项目时无需重新配置。

一个最简可用的配置长这样（我们以连接 Ubuntu 服务器为例）：

{ "type": "sftp", "save_before_upload": true, "upload_on_save": true, "sync_down_on_open": false, "sync_skip_deletes": false, "confirm_downloads": false, "confirm_sync": true, "confirm_overwrite_newer": false, "host": "192.168.1.100", "user": "deploy", "password": "your_password_here", "port": "22", "remote_path": "/var/www/myapp/", "ignore_regexes": [ "\\.sublime-project", "\\.sublime-workspace", ".git", ".DS_Store" ] }

这里每一项都不是随便写的，背后都有明确意图：

• "type": "sftp"：声明协议类型，SFTP 插件还支持ftp、ftps，但sftp是唯一推荐选项（加密传输、权限保留）；
• "save_before_upload": true：确保你 Ctrl+S 时，先保存本地临时副本，再上传——防止网络中断导致本地文件丢失；
• "upload_on_save": true：这是核心开关！设为true才实现“保存即同步”；
• "sync_down_on_open": false：设为false是为了性能。如果设为true，每次你双击打开一个远程文件，插件都会先GET一次最新版本（可能很慢），再打开。对于只读场景有用，但日常编辑中，我们信任自己刚保存的内容，不需要每次都拉取；
• "confirm_overwrite_newer": false：关键安全阀！当远程文件比本地新（比如别人在服务器上直接改了config.php），插件默认会阻止你覆盖。设为false表示“我确认要覆盖”，但前提是你要知道风险——所以我在团队规范里强制要求：所有生产环境配置，必须设为true，强制弹窗确认；
• "remote_path": "/var/www/myapp/"：注意结尾的/！缺了它，插件会把整个myapp目录当成文件名，导致连接失败。这是新手踩坑率最高的地方；
• "ignore_regexes"：正则表达式数组，匹配的文件/目录将被忽略同步。.git必须加，否则你上传时会把整个.git目录传到服务器，暴露 commit history。

注意：密码明文写在配置里是危险的！生产环境必须用密钥认证。我们会在 3.3 节详细讲如何生成和配置密钥，这里先让你跑通流程。

3.3 密钥认证：三步搞定免密登录，比输密码安全十倍

用密码登录不仅麻烦，更致命的是：一旦配置文件泄露（比如误传到 GitHub），密码就全暴露了。密钥认证才是正道。它分三步，每步我都实测过：

第一步：在本地生成密钥对

打开终端（Windows 用 Git Bash 或 WSL），运行：

ssh-keygen -t ed25519 -C "your_email@example.com" -f ~/.ssh/sublime_sftp_key

• -t ed25519：指定密钥类型为 Ed25519（比 RSA 更快更安全，OpenSSH 6.5+ 支持）；
• -C：添加注释，方便识别这是给 Sublime 用的；
• -f：指定密钥文件名，这里叫sublime_sftp_key（私钥）和sublime_sftp_key.pub（公钥）。

按回车跳过密码短语（如果你设了，每次连接都要输，违背“免密”初衷）。

第二步：把公钥复制到服务器

ssh-copy-id -i ~/.ssh/sublime_sftp_key.pub deploy@192.168.1.100

如果ssh-copy-id不可用（如老系统），手动复制：

cat ~/.ssh/sublime_sftp_key.pub | ssh deploy@192.168.1.100 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

第三步：修改配置文件，启用密钥

把之前sftp-config.json里的password字段删掉，加上：

"private_key": "/Users/yourname/.ssh/sublime_sftp_key", "passphrase": ""

• "private_key"：填你本地私钥的绝对路径（Windows 用双反斜杠C:\\Users\\name\\.ssh\\sublime_sftp_key）；
• "passphrase"：如果生成时没设密码，就留空字符串""；如果设了，这里填密码（但不推荐）。

现在，你右键文件夹 →SFTP > Map to Remote...，就会用密钥自动登录，全程无交互。我团队所有成员的配置文件里，password字段都是被注释掉的，CI/CD 流水线也只认密钥——这是安全基线。

4. 实操过程与核心环节实现：从连接服务器到修改 Docker 容器内文件的完整链路

现在我们进入最硬核的部分：如何把 SFTP 插件的连接能力，延伸到 Docker 容器内部？很多人以为“容器没 SSH 就没法连”，这是最大误区。Docker 容器本质是进程隔离的 Linux 环境，只要它能跑sshd，就能被 SFTP 连接。我们分两种典型场景实操：

4.1 场景一：服务器上已有sshd，直接连接（最常见）

假设你的 Ubuntu 服务器 IP 是192.168.1.100，已创建用户deploy，sshd正在运行（默认开启）。这是最简单的情况：

1. 在本地新建文件夹~/projects/nginx-config；
2. 在该文件夹内创建sftp-config.json，内容如前文所示（host、user、private_key 填好）；
3. 在 Sublime Text 中，File > Open Folder...，选择~/projects/nginx-config；
4. 右键左侧边栏的文件夹名 →SFTP > Map to Remote...；
5. 插件会尝试连接，成功后边栏会显示远程目录树（如/etc/nginx/conf.d/）；
6. 双击default.conf，文件在 Sublime 中打开；
7. 修改root /var/www/html;为root /var/www/test;，Ctrl+S；
8. 查看 Sublime 状态栏右下角，会显示Uploading default.conf...→Upload complete；
9. 登录服务器执行ls -l /etc/nginx/conf.d/default.conf，确认 owner 是deploy，时间戳是当前时间。

实操心得：第一次连接时，如果状态栏一直显示Connecting...，大概率是防火墙或sshd配置问题。立刻执行ssh -v deploy@192.168.1.100，看详细日志。常见原因有：/etc/ssh/sshd_config里PasswordAuthentication no但你没配密钥；AllowUsers没包含deploy；UFW 防火墙没放行 22 端口。别猜，用ssh -v看真实报错。

4.2 场景二：连接 Docker 容器（无需修改镜像，5 分钟搞定）

这才是体现 SFTP 插件威力的地方。很多容器（如nginx:alpine、python:3.9-slim）默认不带sshd，但我们不需要重做镜像。利用 Docker 的--entrypoint和--cap-add=SYS_ADMIN，可以动态注入sshd进程。以调试一个 Python Flask 应用为例：

前提：你的容器正在运行，ID 是abc123，应用代码在/app目录。

步骤一：进入容器，安装并启动sshd（临时）

# 进入容器 docker exec -it abc123 sh # Alpine Linux（nginx:alpine） apk add --no-cache openssh-server mkdir -p /var/run/sshd ssh-keygen -A # 创建 deploy 用户（避免用 root） adduser -D -u 1001 deploy echo 'deploy:password123' | chpasswd # 启动 sshd（前台运行，不 daemonize） /usr/sbin/sshd -D -e

注意：-D参数让sshd前台运行，-e输出日志到 stderr，这样docker exec才能捕获。容器退出时sshd自动停止，完全无残留。

步骤二：在宿主机上，用docker port映射 SSH 端口

# 查看容器 sshd 绑定的端口（默认 22） docker port abc123 22 # 如果没映射，手动映射（假设宿主机用 2222 端口） docker port abc123 2222:22

步骤三：配置 SFTP 连接容器

在本地新建文件夹~/projects/flask-app-remote，创建sftp-config.json：

{ "type": "sftp", "save_before_upload": true, "upload_on_save": true, "host": "127.0.0.1", "user": "deploy", "password": "password123", "port": "2222", "remote_path": "/app/", "ignore_regexes": [".git", "__pycache__", "*.pyc"] }

关键变化：

• "host": "127.0.0.1"：因为docker port把容器 22 端口映射到了宿主机 localhost 的 2222；
• "port": "2222"：必须匹配docker port显示的端口；
• "remote_path": "/app/"：直接指向容器内应用代码路径。

现在，Map to Remote...，双击/app/app.py，修改return "Hello World!"为return "Hello from SFTP!"，Ctrl+S —— 保存瞬间，容器内的文件就变了。你甚至不用docker restart，如果应用支持热重载（如 Flask debug mode），刷新浏览器就能看到效果。

实操心得：有人问“能不能不进容器装 sshd？”。可以，但更麻烦。比如用docker cp把预编译的sshd二进制拷进去，或者用docker commit生成新镜像。但我们的目标是“快速调试”，不是“构建生产镜像”。临时起sshd是最快路径，且完全符合 Docker 的“进程即容器”哲学——你起一个sshd进程，它就是一个调试会话，关掉就干净退出，不留痕迹。

4.3 进阶技巧：多环境一键切换与批量同步

一个项目常有 dev/staging/prod 多套环境。SFTP 插件支持“配置文件继承”，用_开头的配置文件作为模板。例如：

• sftp-config.json（主配置，用于 staging）：

  { "type": "sftp", "host": "staging.example.com", "user": "staging", "private_key": "~/.ssh/staging_key", "remote_path": "/var/www/staging/" }

• _sftp-config.json（模板，定义通用规则）：

  { "save_before_upload": true, "upload_on_save": true, "confirm_overwrite_newer": true, "ignore_regexes": [".git", ".env"] }

当插件读取sftp-config.json时，会自动合并_sftp-config.json的字段。这样，你只需改 host/user/remote_path，通用规则复用，避免重复劳动。

批量同步也很实用。比如要更新所有 Nginx 配置：

1. 在本地~/projects/nginx-all文件夹下，为每个站点建子文件夹：site-a/、site-b/；
2. 每个子文件夹里放自己的sftp-config.json（不同 host/path）；
3. 在 Sublime 中File > Add Folder to Project...，把nginx-all加进来；
4. 右键site-a→SFTP > Upload Folder，它会递归上传整个文件夹；
5. 按住Ctrl（Windows）或Cmd（macOS），多选site-a、site-b，右键 →SFTP > Upload Folder，批量上传。

注意：批量操作前务必确认confirm_sync设为true，避免误删。我团队有个血泪教训：某次Upload Folder时忘了取消勾选Delete remote files not in local，结果把线上logs/目录清空了。现在我们所有配置里，这一项默认是false，必须手动勾选才生效。

5. 常见问题与排查技巧实录：那些官方文档没写的坑，我都替你踩过了

SFTP 插件很稳定，但实际落地时，总有些“看似正常却死活连不上”的诡异问题。我把十年间遇到的高频问题整理成速查表，并附上独家排查法。这些问题，90% 的教程都不会提，因为它们藏在环境细节里。

5.1 连接超时（Connection timed out），但ssh命令能连

现象：Sublime 状态栏显示Connecting to 192.168.1.100...，10 秒后变红报错，而你在终端执行ssh deploy@192.168.1.100秒连。

原因与排查：

• SFTP 插件默认用 IPv4，但服务器 DNS 解析返回 IPv6 地址。ssh命令会自动 fallback，插件不会。
  • ✅ 解决：在sftp-config.json里加"ip_version": 4；
• 服务器sshd_config里UseDNS yes导致反向 DNS 查询超时（尤其内网无 DNS 服务器时）。
  • ✅ 解决：sudo nano /etc/ssh/sshd_config，设UseDNS no，然后sudo systemctl restart sshd；
• SELinux 强制策略拦截 SFTP 连接（CentOS/RHEL 默认开启）。
  • ✅ 解决：sudo setsebool -P ssh_sysadm_login on，或临时关闭sudo setenforce 0测试。

我的排查口诀：先看ssh -v日志，再查journalctl -u sshd -f实时日志，最后抓包sudo tcpdump -i any port 22 -w ssh.pcap。三者结合，99% 的连接问题无处遁形。

5.2 上传后文件权限错误（Permission denied when reading）

现象：文件成功上传，但 Nginx 报403 Forbidden，ls -l发现文件 owner 是root，不是www-data。

原因：你用root用户登录了 SFTP，但 Web 服务以www-data运行，无权读取root文件。

解决方案（三选一）：

• ✅推荐：用 Web 服务同用户登录。如 Nginx，创建www-data用户（sudo usermod -a -G www-data deploy），配置中user改为www-data；
• ✅次选：在sftp-config.json里加"file_permissions": "644"和"dir_permissions": "755"，但这只能设权限位，不能改 owner；
• ✅终极：在服务器上设umask 002（让新文件默认 group-writable），并确保deploy用户在www-data组里。

实操心得：永远不要用root连 SFTP！我见过太多人因为图省事用 root，结果改坏/etc/passwd，服务器直接瘫痪。创建专用用户，分配最小必要权限，是运维铁律。

5.3 Docker 容器内sshd启动失败：Could not load host key

现象：docker exec进容器执行/usr/sbin/sshd -D -e，报错Could not load host key: /etc/ssh/ssh_host_rsa_key。

原因：Alpine 的openssh-server包不自动生成 host key，需要手动ssh-keygen -A。

验证：ls -l /etc/ssh/ssh_host_*_key，如果文件不存在，就是这个问题。

解决：在docker exec里执行ssh-keygen -A（生成所有类型 host key），再启sshd。注意：ssh-keygen -A必须在sshd启动前执行，且需 root 权限。

5.4 中文文件名乱码（显示为?????.txt）

现象：服务器上文件名是配置说明.txt，在 Sublime 边栏显示为?????.txt，双击打不开。

原因：SFTP 协议本身不传输字符编码，插件默认用 UTF-8，但某些老系统（如 CentOS 6）用zh_CN.GB18030。

解决：在sftp-config.json里加"charset": "GB18030"（根据服务器 locale 设置，用locale命令查看）。

注意：改charset后需重启 Sublime，因为插件在启动时读取配置。这是少数需要重启的配置项。

5.5 “Upload on Save” 失效，Ctrl+S 没反应

现象：配置里"upload_on_save": true，但保存后状态栏没提示，服务器文件也没变。

排查清单（按顺序）：

1. ✅ 确认你编辑的是远程映射的文件（路径显示sftp://...），不是本地副本；
2. ✅ 检查文件是否在ignore_regexes列表里（如.env文件默认被忽略）；
3. ✅ 查看 Sublime 控制台（Ctrl+）是否有SFTP: Error uploading...` 错误；
4. ✅ 确认remote_path结尾有/（这是最高频原因！）；
5. ✅ 临时把confirm_sync设为false，排除弹窗阻塞。

我的终极调试法：在sftp-config.json里加"log_level": 2，然后Ctrl+` 打开控制台，看详细日志。日志里会显示“正在上传哪个文件”、“用了什么参数”，一目了然。

6. 安全加固与生产环境最佳实践：让 SFTP 连接经得起审计

在测试环境玩得转，不等于能在生产环境上线。SFTP 插件本身是安全的，但你的使用方式决定最终风险等级。以下是我在金融、医疗类客户项目中强制推行的 5 条红线，每一条都来自真实审计事件：

6.1 密钥管理：绝不允许密码认证，且密钥必须有密码短语

• ❌ 禁止：配置文件里出现"password": "xxx"；
• ✅ 强制：所有生产环境连接，必须用 Ed25519 密钥，且密钥生成时必须设置密码短语（passphrase）；
• ✅ 工具：用ssh-agent管理密钥，eval $(ssh-agent)后ssh-add ~/.ssh/prod_key，Sublime 配置里"passphrase"留空，由 agent 提供；
• ✅ 审计点：定期检查服务器~/.ssh/authorized_keys，删除超过 90 天未使用的密钥。

为什么必须设密码短语？因为私钥文件一旦被盗（如笔记本失窃），没有密码短语，攻击者秒连所有服务器。设了密码短语，他至少要暴力破解——而 Ed25519 的破解难度，远高于你的业务系统密码。

6.2 连接粒度：一个配置文件，只对应一个最小权限用户

• ❌ 禁止：用同一个deploy用户连接所有环境（dev/staging/prod）；
• ✅ 强制：为每个环境创建独立用户，如prod-web、staging-api，并用chroot限制其只能访问/var/www/prod目录；
• ✅ 配置：/etc/ssh/sshd_config添加：

  Match User prod-web ChrootDirectory /var/www/prod AllowTcpForwarding no X11Forwarding no

• ✅ 效果：即使prod-web密钥泄露，攻击者也无法跳出/var/www/prod，更无法执行rm -rf /。

6.3 文件同步策略：禁用自动删除，所有变更留痕

• ❌ 禁止：配置中"sync_skip_deletes": false（默认值，意味着上传时会删远程多余文件）；
• ✅ 强制：所有生产环境配置，必须设"sync_skip_deletes": true，并手动管理删除；
• ✅ 补充：在sftp-config.json里加"history_path": "/tmp/sftp-history"，插件会记录每次上传/下载的文件、时间、操作者（需 Sublime Text 4+）；
• ✅ 审计：每天自动脚本检查/tmp/sftp-history，邮件告警异常操作（如凌晨 3 点修改nginx.conf）。

6.4 Docker 容器调试：严禁在生产容器中长期运行sshd

• ❌ 禁止：docker run -d --name prod-app -p 80:80 myimage后，再docker exec进去起sshd；
• ✅ 强制：调试只在staging环境进行；生产环境用kubectl exec或docker exec -it临时进入，改完立即退出；
• ✅ 替代方案：为生产容器添加健康检查探针（如/healthz），用 API 而非文件系统调试；
• ✅ 理由：sshd是额外攻击面，生产容器应遵循“一个容器一个进程”原则，减少 CVE 风险。

6.5 配置文件保护：Git 仓库中永不提交敏感配置

• ❌ 禁止：sftp-config.json提交到 GitHub/GitLab；
• ✅ 强制：在项目根目录.gitignore里加sftp-config.json，并创建sftp-config.json.example（含占位符）；
• ✅ 团队规范：新成员入职，由 DevOps 提供加密的sftp-config.json.gpg，用gpg -d sftp-config.json.gpg > sftp-config.json解密；
• ✅ 工具：用git-secrets扫描，禁止提交含password、private_key的文件。

最后分享一个真实案例：某客户因sftp-config.json误传 GitHub，导致攻击者获取密钥，进而控制其 Kubernetes 集群。根源不是 SFTP 插件，而是配置管理流程缺失。技术再好，流程不闭环，就是裸奔。

7. 性能优化与高级技巧：让 SFTP 连接快如本地，支持超大文件

SFTP 插件默认配置，在千兆内网下上传 10MB 文件约 3 秒，但面对日志分析、数据库 dump 等大文件场景，还能更快。以下是经过压测验证的优化方案：

7.1 TCP 层优化：提升吞吐量 40%

在sftp-config.json里加：

"connect_timeout": 30, "keep_alive_interval": 60, "compression": true, "ssh_options": [ "-o ConnectTimeout=30", "-o ServerAliveInterval=60", "-o Compression=yes", "-o CompressionLevel=9", "-o TCPKeepAlive=yes" ]

• "compression": true：启用 SSH 压缩，对文本文件（HTML/CSS/JS/Log）压缩率高达 70%，实测 100MB 日志文件上传从 85 秒降到 32 秒；
• "ssh_options"：直接透传 OpenSSH 参数，CompressionLevel=9是最高压缩（CPU 换带宽），内网环境推荐；
• "keep_alive_interval": 60：每 60 秒发心跳包，防止 NAT 超时断连（尤其云服务器）。

注意：compression对二进制文件（如图片、PDF）无效，甚至可能略增体积，所以仅在ignore_regexes里排除二进制扩展名。

7.2 大文件上传：绕过 Sublime 内存限制

Sublime Text 本身对超大文件（>100