多光标操作本身不耗内存，真正吃资源的是触发全文本扫描的后续操作（如ctrl+h、ctrl+shift+f或粘贴大段内容），尤其在大文件、启用正则时会导致plugin_host内存飙升甚至卡死。
多光标操作本身不耗内存，但触发全文本扫描才真吃资源
Sublime Text 的多光标（Ctrl+Click / Ctrl+D / Ctrl+Shift+L）本身几乎不占额外内存，真正让内存飙升的是：你在多光标选中大量文本后，紧接着执行了 Ctrl+H（替换）、Ctrl+Shift+F（全局搜索）、或粘贴大段内容——这些操作会强制 Sublime 加载并扫描所有匹配行的上下文，尤其当文件含数千行、且正则启用时，plugin_host 进程可能瞬间吃掉 800MB+ 内存。
常见现象：选中 500 行日志后按 Ctrl+H 输入正则 \d{4}-\d{2}-\d{2}.*ERROR，界面卡死、光标消失、任务管理器里 plugin_host.exe 占用飙升到 1.4GB。
- 别在 >5MB 的单文件里用多光标批量操作；超过 10 万行就视为高危场景
- 禁用正则替换时的“实时预览”：在
Find面板右下角关掉Regex按钮旁的Live小开关（它会让 Sublime 每次按键都重扫全文） - 替换前先确认范围：用
Ctrl+Shift+F先搜一遍，看“Found in X files, Y matches”是否合理；若显示“12000+ matches”，立刻中止，改用命令行sed或awk处理
为什么 Ctrl+Shift+L（行转多光标）比 Ctrl+D 更危险
Ctrl+D 是逐词扩展选区，Sublime 只维护当前光标位置和匹配词索引；而 Ctrl+Shift+L 会为**每一行末尾**插入一个光标，哪怕该行为空或只有空格——这意味着它实际生成了 N 个独立光标对象，并触发行号渲染、高亮更新、软换行计算等 UI 开销。当处理 3000 行以上文件时，UI 线程直接阻塞，sublime_text.exe 内存增长不可逆。
- 替代方案：用
Ctrl+Shift+P→Split into Lines（需安装 Vintageous 插件）或原生命令edit_settings中加"split_into_lines": true（仅 ST4 支持） - 临时禁用行号和高亮：在用户设置中加
"line_numbers": false和"highlight_line": false，操作完再开回来 - 绝对不要对含折叠区块的长文件用
Ctrl+Shift+L—— 折叠状态会迫使 Sublime 解析全部隐藏内容以定位光标位置
多光标 + 插件 = 内存泄漏加速器
多数 LSP 插件（如 LSP-pyright、LSP-typescript）会在每个光标位置触发语义分析请求。当你用 Ctrl+D 选中 200 个函数名，插件会并发发 200 次类型查询，plugin_host 进程缓存堆积、GC 不及时，内存只增不减。
- 操作前先切到安全模式：
subl --safe-mode启动（Windows/macOS/Linux 均可用），跳过所有插件 - 或临时禁用 LSP：命令面板输入
LSP: Toggle Language Server，停掉当前项目语言服务器 - 检查
Packages/User/LSP.sublime-settings是否含"enabled": true和"auto_complete": true，这两项在多光标场景下最伤
删缓存也救不了已卡死的多光标现场
一旦因多光标操作导致 Sublime 卡死、内存锁死，删 Cache 或改 index_files 都无效——此时 plugin_host 进程已进入不可回收状态，唯一解法是强杀进程后重启，且必须清掉 Local/Index 目录，否则下次打开同文件，索引重建过程会复现相同卡顿。
- Windows：任务管理器结束
sublime_text.exe和plugin_host.exe，再删%APPDATA%\Sublime Text\Local\Index - macOS：活动监视器强制退出
Sublime Text和plugin_host，再删~/Library/Application Support/Sublime Text/Local/Index - Linux：运行
pkill -f "sublime_text"; pkill -f "plugin_host"，再删~/.config/sublime-text/Local/Index
记住：多光标不是性能问题的根源，而是把底层索引和插件缺陷暴露出来的扳机。真正要调的，永远是 index_files、folder_exclude_patterns 和插件的自动诊断开关——而不是忍着卡顿去优化操作习惯。
