解决Sublime处理超大文件多行选中时的崩溃问题

处理大文件时，Sublime Text 突然卡死或者选中行时崩溃，这事儿很多人都遇到过。

很多人第一反应是内存不够用，或者文件太大了。其实都不是。问题的根源在于：Sublime 即使在 Plain Text 这种看似“最轻量”的模式下，也默认开启了 gutter（行号区）和 line_numbers。当你用鼠标拖拽着选中百万行时，它得为每一行生成 DOM 节点，去渲染高亮背景、折叠按钮、断点图标这些玩意儿。一旦光标悬停或者你点开右键菜单，像 GitGutter 或 BracketHighlighter 这样的插件就会立刻扫描整个选区，做差异对比或者括号匹配。结果就是 CPU 瞬间飙到 100%，UI 线程直接被卡死。

多行选中崩溃的直接原因是什么

不是在文件打开时崩，而是在你试图选中内容的那一刻。核心就一句话：Sublime 的渲染机制没想过你会对百万行做“选中”这种操作。

怎么让多行选中不崩溃（已打开文件）

操作思路很简单：别等崩溃了再去救火，应该在选中之前就切断渲染链路。

• 按下 Ctrl+Shift+P，输入 Set Syntax: Plain Text 并回车——这一步关掉语法解析器，避免正则匹配干扰到选区计算。
• 再输入 View: Toggle Word Wrap 关闭自动换行——防止超长行在选中时反复计算软换行位置，这也是个隐形杀手。
• 右键点击状态栏上的语言名（比如显示的是 Log），选择 Open all with current extension as… → Plain Text——这样以后打开同后缀文件时，就直接跳过所有“编辑预设”。
• 如果编辑器已经卡死，命令面板都没反应了，别慌。直接终端里运行 subl --safe-mode your_file.log，强制跳过所有插件和用户设置。实测 1.2GB 的日志文件，用这个方式打开后，可以支持 50 万行连续选中，毫无压力。

用户设置里必须加的防崩溃配置

光靠临时关闭可不够，得让 Sublime 从加载第一个字节起就放弃“多行可交互”的幻想。以下配置建议直接写进用户设置：

• "large_file_size_limit": 100——单位是 MB。文件大小超过 100MB 时，自动跳过语法分析、折叠功能和符号索引。注意，这个设置对已经打开的文件不生效，得提前配好。
• "index_files": false——关掉后台全文索引。否则像 SublimeLinter 和 GitGutter 这类插件，会在你选中内容时启动子进程扫描整个文件，等于雪上加霜。
• "gutter": false 和 "line_numbers": false——彻底移除行号区的 DOM 节点。没了这些节点，多行选中时就不需要触发重绘了，性能提升立竿见影。
• "viewport_size": 5000——单次最多渲染 5000 个字符，默认值是 100000。这个设置必须配合 "word_wrap": false 才能生效，否则超长行照样拖垮渲染器。
• "ask_before_opening_large_files": false——不要弹出确认框。因为点了“Yes”之后，编辑器还会偷偷建立索引、检测缩进，这些操作都会成为隐患。

真正要小心的隐藏坑

很多人加了 large_file_size_limit 就以为万事大吉了，但 Sublime 的崩溃往往发生在你“以为已经轻量加载”的时候。

举个例子：你装了 BracketHighlighter 插件，它会默认对任意选区做括号匹配。再比如你设了 "highlight_line": true，光标一移到选区中间，它就开始高亮整行，进而触发 gutter 图标重绘。这些都是“打开不崩，一选中就崩”的典型场景。而且这类崩溃不会报错，表现形式就是 UI 冻结、鼠标消失、Ctrl+C 失效。

遇到这种情况，别硬等。直接关掉相关插件，或者干脆切到 --safe-mode 模式。记住，问题的核心不是文件有多大，而是你的编辑器在选中操作那一刻，有没有扛住渲染压力的能力。