Sublime Text远程编辑内存暴涨的根本原因是其索引器将sshfs挂载的远程路径视作本地目录暴力扫描，导致I/O阻塞与缓存膨胀；必须禁用index_files、硬排除远程路径并关闭语法解析。
Sublime Text 本身不支持原生远程编辑（如通过 SSH 直接打开远程文件），所谓“远程编辑”实际是以下三种场景之一：本地挂载远程文件系统（如 sshfs）、用插件同步文件（如 SFTP）、或配合终端工具（如 rsync + 本地编辑）。内存问题不是出在“远程”上，而是出在 Sublime 加载、解析、索引这些**被当作本地文件处理的远程路径内容**上。
为什么 sshfs 挂载后 Sublime 内存暴涨
当用 sshfs 把远程目录挂到 /mnt/remote，再在 Sublime 中添加该路径为项目文件夹时，Sublime 不会区分“本地”还是“远程”——它只看到一个路径。一旦 index_files 开启，它就会尝试递归 stat() 和 read() 每个文件，包括 node_modules 或日志目录。网络延迟叠加文件数量，导致 plugin_host 卡在 I/O 等待中，内存持续增长甚至假死。
- 现象：打开项目几秒后，
plugin_host进程内存升至 1.5GB+，UI 停滞，Ctrl+P 无响应 - 根本原因：Sublime 的索引器不支持异步/超时/断连重试，遇到慢响应的 sshfs 文件就阻塞并缓存中间状态
- 必须禁用
index_files，且必须配合folder_exclude_patterns排除所有远程子目录（仅用户设置不够）
SFTP 插件打开大文件时的内存陷阱
SFTP 插件（如 sublime-sftp）默认把远程文件下载到临时目录再打开。若远程是 200MB 的日志，它会在 /tmp/sublime_sftp_XXXX 写一份副本，Sublime 接着全量加载——语法高亮 + 行号渲染 + 索引，瞬间吃掉 1.2GB 内存。更糟的是，关闭标签页后临时文件可能残留，下次打开同名文件又触发重复下载。
- 解决方法：在 SFTP 配置里强制设
"download_on_open": false，改用手动右键 → “Download File” 控制时机 - 对已打开的大文件，立即执行
View → Syntax → Plain Text，避免语法解析 - 在用户设置中加
"large_file_size_limit": 50（单位 MB），让 Sublime 对 >50MB 文件自动禁用高亮和行号 - 务必清理
/tmp/sublime_sftp_*（Linux/macOS）或%TEMP%\sublime_sftp_*（Windows）残留文件
如何让 Sublime 安全地配合 rsync / git over SSH
这是最推荐的远程工作流：用命令行同步（rsync -av --delete user@host:/path/ ./local/），只在本地编辑，再推回。但很多人忽略关键细节——如果本地目录软链接到远程挂载点，或 .git 配置了 core.fsmonitor 指向远程路径，Sublime 仍会误触远程 I/O。
- 检查项目根目录是否含软链接指向
/mnt/remote或/Volumes/remote，若有，删掉并改用真实路径 - 运行
git config --get core.fsmonitor，若输出类似/path/to/remote/fsmonitor，执行git config --unset core.fsmonitor - 在项目配置（
Project → Edit Project）中显式排除所有可能关联远程的路径："folder_exclude_patterns": [".git/modules", ".git/worktrees", "/mnt/", "/Volumes/"] - 同步后首次打开项目前，先彻底退出 Sublime，再删除
Cache和Index目录（否则旧远程索引残留仍在）
真正危险的不是“远程”，而是 Sublime 把网络延迟路径当成本地磁盘暴力扫描。所有优化都围绕一个动作：让它别碰那些路径——不是靠猜，而是用 folder_exclude_patterns 硬隔离，用 index_files: false 断源头，用 Plain Text 拦解析。任何漏掉其中一环，内存都会在你切回编辑器时突然顶满。
