1. 项目概述：为什么在 Sublime Text 里直连服务器改文件，比“下载→编辑→上传”强十倍

你有没有过这样的时刻：凌晨两点，线上一个 CSS 样式错位导致用户投诉激增，你火速登录服务器，用 nano 或 vim 在终端里硬着头皮改样式表——结果手一抖少打了个分号，整个页面白屏；又或者，你刚在 Docker 容器里部署好 Python Web 应用，想快速调试一个路由逻辑，却得先 docker exec -it app bash ，再 apt install vim （容器里甚至没装！），再一层层 cd /app/src/views/ 找到对应文件，改完还得 exit 、 docker restart ……等服务重启完，用户已经截图发微博了。这不是虚构场景，是我过去三年在五家不同规模公司做后端和 DevOps 支持时，每天重复上演的“救火三部曲”。

这个标题说的，就是把 Sublime Text 变成你的“远程工作台”——不是靠 FTP 客户端跳来跳去，也不是靠 VS Code 的 Remote-SSH 插件（它重、吃内存、有时连不上 Docker 容器），而是用 SFTP 协议，让 Sublime Text 像打开本地文件夹一样，直接挂载服务器或容器里的目录，双击即开、Ctrl+S 即存、实时生效。它不替换你的终端，也不替代 CI/CD，但它能让你在 8 秒内完成一次热修复：从发现 bug 到线上验证，全程在同一个编辑器界面完成，无切换、无上下文丢失、无文件覆盖风险。核心关键词是 Sublime Text 、 SFTP 、 Docker 容器 、 远程文件管理 、 实时同步 。适合所有需要频繁修改服务器配置、Nginx 规则、Docker Compose 文件、日志分析脚本、静态资源或轻量级后端模板的开发者、运维、测试工程师——尤其适合那些服务器资源紧张（比如 1C1G 的云主机）、不想装重型 IDE、又拒绝忍受 vim 操作门槛的务实派。

我试过不下七种方案：FileZilla + 手动同步、VS Code Remote-SSH、JetBrains Gateway、WebStorm 的 Deployment 配置、甚至自己写 Python 脚本监听文件变化并 rsync。最后稳定用下来、且在三台生产服务器、十二个不同镜像的 Docker 容器（包括 Alpine、Debian、CentOS 基础镜像）上零故障运行超 14 个月的，就是 Sublime Text + SFTP 插件这套组合。它轻（插件本体不到 200KB）、稳（基于 OpenSSH 底层，协议兼容性极强）、准（修改即刻落盘，无缓存层干扰）、可审计（所有操作生成清晰日志）。下面我就带你从零搭起这条“编辑器直连产线”的通道，不绕弯、不炫技，只讲实测有效的每一步。

2. 整体设计思路与方案选型：为什么是 SFTP，而不是 SSHFS、rsync 或 WebDAV？

2.1 为什么放弃 SSHFS：看似优雅，实则埋雷

SSHFS 确实能让你把远程目录挂载成本地磁盘，比如 sshfs user@server:/var/www /mnt/remote ，然后在 Sublime 里直接打开 /mnt/remote 。听起来很美？我踩过三次坑：第一次，服务器网络抖动 1.2 秒，SSHFS 自动断开，但 Sublime 不知道，你还在编辑，Ctrl+S 后提示“保存失败”，但光标已移走，你根本没注意——结果改了一半的 Nginx 配置被截断写入， nginx -t 直接报错；第二次，在 Docker 容器里跑 SSHFS 客户端？Alpine 镜像默认没装 fuse ，你得 apk add fuse ，但很多生产容器为安全起见禁用了 CAP_SYS_ADMIN ， modprobe fuse 直接 Permission Denied；第三次，Mac 上用 SSHFS 挂载 Linux 服务器，中文文件名显示乱码，查了三天才发现是 iocharset=utf8 参数漏加。这些都不是理论问题，是我在客户现场花 6 小时定位的真实故障。SSHFS 的本质是“文件系统层代理”，它增加了抽象层级，而我们的目标恰恰是 减少中间环节，直达存储 。

2.2 为什么不用 rsync + inotify：自动化陷阱

rsync --watch 或 inotifywait 配合 shell 脚本，实现本地改完自动推送到服务器，这方案在早期小团队很流行。但它有不可忽视的“时间窗口”：假设你本地改了 index.html ，脚本检测到变化，执行 rsync -avz index.html user@server:/var/www/ ，这个过程耗时 300ms～2s（取决于文件大小和网络）。在这期间，如果用户恰好刷新页面，可能加载到旧版 HTML 和新版 CSS 的混合体，出现样式错乱。更致命的是，它无法处理“服务器端主动变更”的场景——比如日志轮转脚本每小时清空 /var/log/app.log ，你的本地副本就永远落后了。SFTP 是双向实时协议，Sublime 通过它打开的文件，本质是建立了一个加密隧道，所有读写操作都经由 SSH 加密通道直达远程文件系统，没有中间缓存，没有异步延迟， 所见即所得，所存即所用 。

2.3 为什么不是 WebDAV 或 SMB：权限与容器适配性硬伤

WebDAV 需要在服务器端额外部署 Apache 或 Nginx 的 dav_module，还要配置 .htaccess 权限、Digest 认证，对 Docker 容器来说，意味着要定制基础镜像、暴露额外端口、增加攻击面——这违背了“最小权限”原则。SMB 更麻烦，Linux 服务器得装 samba ，Windows 容器？几乎没人这么干。而 SFTP 是 OpenSSH 的原生子系统，只要 sshd 在跑（99% 的 Linux 服务器和绝大多数官方 Docker 镜像都默认启用），它就在那里，无需额外安装、无需开放新端口、无需配置新服务。你只需要确保 sshd_config 里有 Subsystem sftp /usr/lib/openssh/sftp-server （Debian/Ubuntu）或 /usr/libexec/openssh/sftp-server （CentOS/RHEL），这两行默认都存在。这是真正的“零配置启动”。

2.4 为什么锁定 Sublime Text + SFTP 插件：轻量与确定性的胜利

VS Code 的 Remote-SSH 功能强大，但它依赖 Node.js 运行时、VS Code Server 进程、以及一套完整的语言服务，启动慢、内存占用高（常驻 500MB+），在低配服务器上容易触发 OOM Killer。而 Sublime Text 启动 < 300ms，内存常驻 < 80MB，它的 SFTP 插件（由 wbond 开发，GitHub 星标 2.4k）是纯 Python 编写，直接调用 Paramiko 库（Python 的 SSH 实现），不依赖外部二进制，编译即用。更重要的是，它对 Docker 容器的支持是“穿透式”的：你不需要在容器里开 SSH 服务，只要容器和宿主机共享 SSH 端口（比如 -p 2222:22 ），或者通过宿主机的 SSH 转发到容器内部（用 ProxyJump ），SFTP 插件就能无缝连接。我实测过 python:3.9-slim 、 node:18-alpine 、 nginx:alpine 三种典型镜像，全部一次连通。这种确定性，在生产环境里比“功能多”重要一百倍。

3. 核心细节解析与实操要点：SFTP 插件配置不是填表，是理解 SSH 信任链

3.1 安装与初始化：别急着点“Map to Remote”

SFTP 插件在 Package Control 里搜 “SFTP” 即可安装（作者 wbond，非其他同名插件）。安装后，不要立刻右键文件夹选 “SFTP > Map to Remote”——这是新手最大误区。正确流程是：先按 Cmd+Shift+P （Mac）或 Ctrl+Shift+P （Win/Linux）打开命令面板，输入 “SFTP: Setup Server Configuration”，回车。这时会生成一个 sftp-config.json 文件， 它必须放在你准备映射的本地项目根目录下 ，而不是 Sublime 的 Packages 目录。为什么？因为 SFTP 插件的设计哲学是“每个项目独立配置”，避免不同服务器的密钥、路径、权限混在一起。比如你有 ~/projects/backend 和 ~/projects/frontend 两个文件夹，它们各自需要连不同的服务器，那么每个文件夹下都要有一个专属的 sftp-config.json ，互不干扰。

提示：如果你用的是 Sublime Text 4，首次运行此命令可能提示 “No folder opened”，此时请先 File > Open Folder... 选中你的本地项目根目录，再执行命令。这是 ST4 的 UI 变更，老用户容易忽略。

3.2 配置文件详解： sftp-config.json 的每一行都在解决一个真实问题

下面是一个生产环境可用的完整配置示例，我逐行解释其背后的工程考量：

{
    "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": "",
    "port": "22",
    "private_key": "/Users/yourname/.ssh/id_rsa_prod",
    "ignore_regexes": [".git/", ".DS_Store", "node_modules/", "__pycache__/", "*.log"],
    "remote_path": "/var/www/myapp/",
    "ftp_version": "auto",
    "connect_timeout": 30,
    "ssh_key_file": "",
    "ssh_key_pass": "",
    "ssh_auth_method": "publickey",
    "preserve_modification_times": true,
    "file_permissions": "0644",
    "dir_permissions": "0755",
    "extra_list_connections": 0,
    "edit_mode": "default"
}

• "type": "sftp" ：固定值，声明协议类型。别写成 "ftp" 或 "sftp2" ，后者不存在。
• "save_before_upload": true ：强制保存本地文件后再上传。这是防止“未保存就上传空文件”的保险丝。我见过同事因误触 Ctrl+S 未生效，直接上传了空白 config.py ，导致服务崩溃。
• "upload_on_save": true ：核心开关。设为 true 才实现“Ctrl+S 即同步”。设为 false 就退化成手动上传模式，失去意义。
• "sync_down_on_open": false ： 强烈建议设为 false 。如果设为 true ，每次你双击打开一个远程文件，插件会先从服务器拉取最新版覆盖本地缓存。这在多人协作时是灾难——A 同事刚改完 nginx.conf 并上传，B 同事还没打开，等 B 打开时，本地看到的是 A 的版本，但 B 的编辑历史是旧的，他 Ctrl+S 会覆盖 A 的修改。设为 false ，你始终编辑的是本地副本，上传时才覆盖远程，符合 Git 式协作直觉。
• "ignore_regexes" ：正则忽略列表。 .git/ 必须加，否则上传整个 .git 目录会暴露 commit hash 和敏感信息； "*.log" 防止误传日志文件（有些日志文件可达 GB 级）； "node_modules/" 是前端项目标配。注意：正则需用 / 包裹，且是相对路径匹配。
• "remote_path": "/var/www/myapp/" ： 末尾必须加 / 。这是血泪教训。不加 / 会导致插件把整个路径当作文本文件名创建，比如你设 "remote_path": "/var/www/myapp" ，它会尝试创建一个叫 myapp 的文件，而不是进入 myapp 目录。加 / 后，它才理解这是目录路径。
• "ssh_auth_method": "publickey" ：明确指定认证方式。虽然密码认证也支持，但生产环境必须用密钥。 "password": "" 留空，插件会自动读取 private_key 指定的私钥文件。
• "preserve_modification_times": true ：保持文件修改时间戳。这对依赖 make 或 rsync 增量构建的流程很重要，避免每次上传都触发全量编译。
• "file_permissions": "0644" ：上传后自动设置文件权限。 0644 是标准文本文件权限（所有者读写，组和其他人只读），比默认的 0600 （仅所有者）更合理，避免 Nginx 因无读权限报 403。

注意： "private_key" 路径必须是绝对路径，且该私钥文件权限必须是 600 （ chmod 600 /path/to/key ）。如果权限太宽松（如 644 ），OpenSSH 会拒绝使用，报错 “Permissions for ‘/path/to/key’ are too open”。

3.3 Docker 容器的特殊连接策略：两种可靠路径，避开“容器无 SSH”陷阱

Docker 容器默认不运行 SSH 服务，这是安全最佳实践。但 SFTP 插件连接的是“SSH 服务”，不是“容器本身”。所以你需要一条通往容器文件系统的 SSH 通道。我验证过两种 100% 可行的方案：

方案一：宿主机 SSH + 容器卷挂载（推荐给大多数场景）
这是最简单、最安全的方式。前提是你已将容器内的应用目录挂载为宿主机目录，例如：

docker run -d \
  --name myapp \
  -v /opt/myapp:/var/www/myapp \  # 关键：宿主机 /opt/myapp 映射到容器内 /var/www/myapp
  -p 80:80 \
  nginx:alpine

此时，你只需在 sftp-config.json 中将 "host" 设为宿主机 IP（如 127.0.0.1 或服务器内网 IP）， "remote_path" 设为宿主机上的挂载点 /opt/myapp/ 。SFTP 插件上传文件到 /opt/myapp/ ，容器内 /var/www/myapp/ 会实时同步，因为这是同一个文件系统。无需在容器里装任何东西，零侵入。

方案二：SSH ProxyJump（推荐给无法挂载卷的场景）
当容器必须用 --tmpfs 或 --read-only 启动，无法挂载宿主机目录时，用 SSH 跳转。假设你的服务器 IP 是 203.0.113.5 ，容器在该服务器上，且你已配置好容器的 SSH 访问（例如用 sshd 镜像或自定义基础镜像）：

# 在服务器上，将容器 22 端口映射到宿主机 2222
docker run -d -p 2222:22 your-ssh-enabled-image

然后在 sftp-config.json 中：

"host": "203.0.113.5",
"port": "2222",
"ssh_auth_method": "publickey",
"private_key": "/path/to/host-key",
"proxy_host": "203.0.113.5",
"proxy_port": "22",
"proxy_user": "root",
"proxy_private_key": "/path/to/host-key"

这里 proxy_* 字段告诉插件：先用 proxy_user 和 proxy_private_key 登录宿主机 203.0.113.5:22 ，再从宿主机发起连接到 203.0.113.5:2222 （即容器）。这利用了 OpenSSH 的 ProxyJump 机制，SFTP 插件原生支持。实测延迟增加 < 50ms，完全可接受。

4. 实操过程与核心环节实现：从第一次连接到热修复线上 Bug 的完整链路

4.1 第一次连接：三步验证法，拒绝“黑盒式成功”

别相信“配置完就能用”。我要求自己每次新配服务器，都执行以下三步验证，缺一不可：

第一步：终端手动 SSH 测试连通性
在本地终端执行：

ssh -i /path/to/private_key deploy@192.168.1.100 -p 22

如果卡住、报错 Connection refused 或 Permission denied ，说明底层 SSH 有问题，SFTP 插件必败。此时应检查：服务器防火墙（ ufw status ）、 sshd 是否运行（ systemctl status sshd ）、用户 deploy 是否在 AllowUsers 列表中、私钥权限是否为 600 。

第二步：SFTP 命令行测试协议层
在终端执行：

sftp -i /path/to/private_key -o Port=22 deploy@192.168.1.100

成功后你会看到 sftp> 提示符。输入 ls /var/www/myapp/ ，看能否列出文件。如果报错 Received message too long ，说明服务器 sshd_config 中 MaxStartups 设置过低，需调大（如 MaxStartups 30:30:100 ）。这一步验证了 SFTP 子系统本身可用，排除了插件之外的所有问题。

第三步：Sublime 内部连接测试
在 Sublime 中，打开项目文件夹，按 Cmd+Shift+P → “SFTP: Browse Remote”，输入配置名（即 sftp-config.json 所在文件夹名），回车。如果弹出远程目录树，且能双击打开文件，说明插件配置成功。此时右键任意文件 → “SFTP: Upload File”，观察右下角状态栏是否显示 “Upload successful”。只有三步全过，才算真正打通。

4.2 修改 Nginx 配置的实战：一次真实的 7 分钟热修复

场景还原：某天下午 3:15，监控告警 www.example.com 返回 502 Bad Gateway。登录服务器 curl -I http://localhost 确认 Nginx 正在运行，但 curl http://localhost:3000 （上游 Node 服务）超时。初步判断是 Nginx 代理超时设置过短。

Step 1：直连 Nginx 配置目录
在本地新建文件夹 ~/nginx-config ，放入 sftp-config.json ，内容如下：

{
    "type": "sftp",
    "save_before_upload": true,
    "upload_on_save": true,
    "sync_down_on_open": false,
    "host": "192.168.1.100",
    "user": "root",
    "port": "22",
    "private_key": "/Users/me/.ssh/id_rsa_root",
    "remote_path": "/etc/nginx/conf.d/",
    "ignore_regexes": [".git/", ".DS_Store"],
    "file_permissions": "0644"
}

注意：这里用 root 用户，因为 /etc/nginx/ 需要 root 权限。 private_key 是服务器 root 用户的私钥。

Step 2：定位并修改文件
在 Sublime 中 File > Open Folder... 选中 ~/nginx-config ，右键 → “SFTP: Browse Remote”，展开 conf.d/ ，找到 example.com.conf 。双击打开，找到 location / { 块，添加两行：

    proxy_read_timeout 300;
    proxy_connect_timeout 300;

Ctrl+S 保存。右下角立即显示 “Uploading example.com.conf… Done”。此时文件已写入服务器 /etc/nginx/conf.d/example.com.conf 。

Step 3：热重载 Nginx，零停机生效
在终端执行：

ssh -i ~/.ssh/id_rsa_root root@192.168.1.100 "nginx -t && nginx -s reload"

输出 nginx: the configuration file /etc/nginx/nginx.conf syntax is ok 和 nginx: configuration file /etc/nginx/nginx.conf test is successful ，表示语法正确且重载成功。整个过程从发现问题到线上生效，耗时 7 分钟 23 秒，全程在 Sublime 一个界面内完成，无需切换终端、无需记忆路径、无需担心文件覆盖。

4.3 Docker 容器内日志分析：用 Sublime 当轻量级 Log Viewer

Docker 容器日志通常存于 /var/lib/docker/containers/<id>/<id>-json.log ，但直接读取原始 JSON 日志体验极差。更好的方式是：在容器内运行 tail -f /app/logs/app.log ，并将该日志文件挂载到宿主机。

Step 1：容器启动时挂载日志卷

docker run -d \
  --name api-service \
  -v /opt/api-logs:/app/logs \  # 宿主机 /opt/api-logs 映射到容器内 /app/logs
  your-api-image

Step 2：为日志目录单独配置 SFTP
新建文件夹 ~/api-logs ， sftp-config.json 中：

"remote_path": "/opt/api-logs/",
"upload_on_save": false,  // 日志只读，禁用上传
"download_on_open": true   // 打开时自动下载最新日志

Step 3：实时分析日志
在 Sublime 中打开 ~/api-logs ，右键 → “SFTP: Browse Remote”，双击 app.log 。插件会自动下载当前文件。按 Cmd+F 搜索 ERROR ，用 Ctrl+Shift+P → “Find: Find All” 高亮所有错误。更妙的是，Sublime 的 Goto Anything （ Cmd+P ）支持正则搜索，输入 @ERROR.*500 可快速跳转到所有 500 错误行。你甚至可以安装 “TrailingSpaces” 插件，一键高亮日志中的多余空格——这在排查 JSON parse error 时极其有用。整个过程比 docker logs -f api-service | grep ERROR 更直观、可追溯、可标记。

5. 常见问题与排查技巧实录：那些文档里不会写的“现场急救包”

5.1 典型问题速查表

问题现象	可能原因	排查命令	解决方案
右下角显示 “Connecting…” 后无响应	服务器防火墙拦截 22 端口	telnet 192.168.1.100 22	在服务器执行 ufw allow 22 （Ubuntu）或 firewall-cmd --permanent --add-port=22/tcp （CentOS）
报错 “Permission denied (publickey)”	私钥文件权限 > 600，或 sshd_config 中 PubkeyAuthentication no	ls -l ~/.ssh/id_rsa ； sudo grep PubkeyAuthentication /etc/ssh/sshd_config	chmod 600 ~/.ssh/id_rsa ； sudo sed -i 's/PubkeyAuthentication no/PubkeyAuthentication yes/g' /etc/ssh/sshd_config && sudo systemctl restart sshd
上传后文件权限变成 0600，Nginx 无法读取	sftp-config.json 中未设置 file_permissions	查看配置文件	添加 "file_permissions": "0644"
修改文件后 Ctrl+S 无反应，状态栏无提示	upload_on_save 设为 false ，或文件不在 remote_path 目录下	检查配置；在 Sublime 中右键文件 → “SFTP: Show File Status”	确保 upload_on_save 为 true ；确认文件路径在 remote_path 下
连接 Docker 容器时报错 “Connection refused”	容器未映射 22 端口，或容器内 sshd 未启动	docker port mycontainer ； docker exec mycontainer ps aux | grep sshd	docker run -p 2222:22 ... ；或改用“宿主机挂载卷”方案

5.2 独家避坑技巧：来自 14 个月生产环境的 5 条铁律

技巧一：永远用 deploy 用户，而非 root ，除非绝对必要
我曾因用 root 用户连接，误删了 /etc/hosts ，导致整台服务器 DNS 失效。后来强制规定：所有 SFTP 配置必须用专用 deploy 用户，该用户仅对 /var/www/ 、 /etc/nginx/ 等必要目录有 rwx 权限，其余一律 r-x 。创建方法：

# 创建用户
sudo adduser deploy --disabled-password
# 设置目录权限
sudo chown -R deploy:deploy /var/www/myapp
sudo chmod -R 755 /var/www/myapp
# 限制 SSH 只能 SFTP（禁用 shell）
echo "deploy:x:1001:1001::/home/deploy:/usr/sbin/nologin:/bin/bash" | sudo tee -a /etc/passwd

这样即使配置文件泄露，攻击者也无法获得 shell 权限。

技巧二：为每个项目生成独立密钥对，命名即含义
不要用同一个 id_rsa 连所有服务器。在 ~/.ssh/ 下创建：

id_rsa_prod_web  # 生产 Web 服务器
id_rsa_staging_db # 预发布数据库服务器
id_rsa_docker_nginx # Nginx 容器

并在 sftp-config.json 中精确引用。好处是：某台服务器密钥泄露，不影响其他；且 ssh-add -l 一眼看出当前加载了哪些密钥。

技巧三：用 sync_skip_deletes: true 防止误删
默认情况下，如果你在本地删除了一个文件，SFTP 插件会同步删除远程文件。这在协作中是定时炸弹。设为 true 后，本地删文件只影响本地，远程文件岿然不动。需要删远程文件？右键 → “SFTP: Delete Remote File”，弹出二次确认框，强迫你思考。

技巧四： connect_timeout 必须设为 30，而非默认 5
默认 5 秒超时在高延迟网络（如跨国云服务器）下极易失败。我遇到过客户在新加坡服务器，上海办公室 ping 延迟 120ms，但 sftp 连接常因握手慢于 5 秒而中断。设为 30 后，100% 连通。这不是妥协，是适应真实网络。

技巧五：定期导出连接日志，用于审计
SFTP 插件会在 ~/Library/Application Support/Sublime Text 3/Packages/User/SFTP/logs/ （Mac）或 %APPDATA%\Sublime Text 3\Packages\User\SFTP\logs\ （Win）生成详细日志。我写了个小脚本，每天凌晨 3 点压缩昨日日志并上传到内部 S3：

#!/bin/bash
DATE=$(date -d "yesterday" +%Y%m%d)
tar -czf /tmp/sftp-log-$DATE.tar.gz ~/Library/Application\ Support/Sublime\ Text\ 3/Packages/User/SFTP/logs/*.log
aws s3 cp /tmp/sftp-log-$DATE.tar.gz s3://internal-logs/sftp/

这样，当有人问“昨天谁改了数据库配置？”，你能在 10 秒内给出答案。

6. 进阶扩展与安全加固：让这套方案扛住企业级考验

6.1 多服务器一键切换：用 Sublime 工作区（Workspace）管理复杂拓扑

大型项目常涉及多个环境：开发（Dev）、预发布（Staging）、生产（Prod），每个环境又有 Web 服务器、API 服务器、数据库服务器。为每个环境建一个文件夹太散乱。解决方案：用 Sublime 的 .sublime-project 工作区文件统一管理。

在项目根目录创建 myapp.sublime-project ，内容如下：

{
    "folders": [
        {
            "path": "."
        }
    ],
    "settings": {
        "tab_size": 2,
        "translate_tabs_to_spaces": true
    },
    "build_systems": [
        {
            "name": "SFTP Dev",
            "cmd": ["sh", "-c", "cd ~/projects/myapp-dev && sftp -F ./sftp-config-dev.json"],
            "selector": "source.sftp"
        },
        {
            "name": "SFTP Prod",
            "cmd": ["sh", "-c", "cd ~/projects/myapp-prod && sftp -F ./sftp-config-prod.json"],
            "selector": "source.sftp"
        }
    ]
}

然后在 ~/projects/myapp-dev/ 和 ~/projects/myapp-prod/ 下分别放对应的 sftp-config-dev.json 和 sftp-config-prod.json 。按 Cmd+Shift+P → “Project: Switch Project”，即可在 Dev 和 Prod 配置间秒切。工作区文件可提交到 Git（去掉敏感字段如 private_key ），团队新人 git clone 后，只需替换自己的私钥路径，即可开箱即用。

6.2 安全加固：三道防线，让 SFTP 连接坚如磐石

防线一：SSH 密钥强度强制升级
停止使用 RSA 1024 位密钥。生成新密钥时，必须用：

ssh-keygen -t ed25519 -C "deploy@mycompany.com" -f ~/.ssh/id_ed25519_prod

ed25519 是现代标准，比 RSA 2048 更快、更安全。在服务器 sshd_config 中添加：

HostKey /etc/ssh/ssh_host_ed25519_key
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com

重启 sshd ，用 ssh -Q cipher 验证新算法已启用。

防线二：SFTP 插件配置文件权限锁死
~/.ssh/ 目录权限必须是 700 ， sftp-config.json 文件权限必须是 600 ：

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519_prod
chmod 600 ~/projects/myapp-prod/sftp-config.json

否则 Sublime 启动时会警告 “Insecure file permissions”，并可能拒绝加载配置。

防线三：服务器端 SFTP Chroot 隔离
为 deploy 用户设置 Chroot，将其限制在 /var/www/ 目录，无法 cd .. 到根目录：

# 创建 Chroot 目录结构
sudo mkdir -p /var/www/chroot/{dev,etc,lib,lib64,usr/bin}
sudo mknod /var/www/chroot/dev/null c 1 3
sudo mknod /var/www/chroot/dev/zero c 1 5
# 修改 sshd_config
echo "Match User deploy" | sudo tee -a /etc/ssh/sshd_config
echo "    ChrootDirectory /var/www/chroot" | sudo tee -a /etc/ssh/sshd_config
echo "    ForceCommand internal-sftp" | sudo tee -a /etc/ssh/sshd_config
echo "    AllowTcpForwarding no" | sudo tee -a /etc/ssh/sshd_config
sudo systemctl restart sshd

此时 deploy 用户只能访问 /var/www/ 下的文件，彻底杜绝越权访问。

6.3 性能优化：应对大文件与高并发编辑

当你要编辑一个 50MB 的 SQL 导出文件，或同时有 3 个同事在改同一套 Nginx 配置时，SFTP 插件可能卡顿。优化方案：

• 大文件处理 ：在 sftp-config.json 中添加 "large_file_threshold": 10000000 （单位字节，即 10MB）。超过此阈值的文件，插件会以流式方式上传，避免内存爆满。
• 并发编辑保护 ：启用 confirm_overwrite_newer: true 。当远程文件比本地新（比如同事刚上传），插件会弹窗提示：“Remote file is newer. Overwrite?”，给你选择“Compare”（用 Sublime 内置 diff 对比）、“Overwrite” 或 “Cancel”。这比 Git 的 merge 冲突更轻量，更适合配置文件协作。
• 连接池复用 ：设置 "extra_list_connections": 2 。默认为 0，即每次 ls 都新建连接。设为 2 后，插件会维护 2 个长连接， ls 、 stat 等元数据操作复用连接，速度提升 3 倍。

这套方案，我已在金融、电商、SaaS 三类客户的生产环境中稳定运行。它不追求“炫技”，只解决一个朴素问题：让修改服务器文件这件事，回归到它本该有的样子——简单、直接、可靠。当你下次再被一个线上 CSS bug 惊醒，打开 Sublime，双击 styles.css ，改完 Ctrl+S，喝口咖啡看监控曲线平滑回落，你会明白，所谓效率革命，往往就藏在这样一个被