真正拖慢大文件的是match_brackets、highlight_line和word_wrap；关闭这三项可显著提升性能，其中match_brackets因深度正则扫描导致卡顿最隐蔽。
关闭括号匹配本身对大文件卡顿影响极小，真正拖慢的是语法高亮、行号渲染、自动换行和括号高亮（match_brackets）这四类行为——但如果你在打开大文件后仍看到光标停在{或(上时界面卡顿，那大概率是match_brackets触发了深度正则扫描，尤其在超长单行 JSON 或日志里。
为什么关掉 auto_match_enabled 不能解决大文件卡顿
auto_match_enabled 控制的是“输(时自动补)”这种输入行为，只在你打字瞬间生效；它不参与文件加载、不扫描全文、也不影响滚动。卡顿根源是：match_brackets（括号高亮）会在光标移动到任一括号字符时，实时向前后遍历匹配，遇到百万字符无换行的单行内容，直接触发 O(n) 甚至回溯型正则，CPU 拉满。
-
match_brackets默认为true，且优先级高，即使你关了语法高亮也照常运行 - 它不依赖语法识别——哪怕当前是
Plain Text模式，只要光标落在{[()等字符上就会启动 - 在大日志或导出 JSON 中，一行含数万字符时，一次高亮匹配可能耗时数百毫秒，连续滚动就假死
必须关掉的三项：不是 auto_match_enabled，而是这三个
打开 Preferences → Settings – User，在右侧用户设置中加入以下三行（确保是合法 JSON，逗号位置正确）：
"match_brackets": false, "highlight_line": false, "word_wrap": false
-
match_brackets: 关闭括号高亮，消除最隐蔽的卡点；别信“只是视觉效果”，它真会扫全文 -
highlight_line: 当前行背景高亮在千万行文件里每滚一行都重绘，关掉后滚动帧率立升 -
word_wrap: 超长日志行一旦开启软换行，Sublime 会反复计算断点位置，O(n²) 渲染开销
已打开的大文件卡住时，5 秒内停掉括号高亮
不用重启，不用等加载完成，立刻干预正在运行的实例：
- 按
Ctrl+Shift+P（Windows/Linux）或Cmd+Shift+P（macOS），输入Preferences: Settings – Syntax Specific回车 - 此时会打开一个空的语法专属配置（如
Plain Text.sublime-settings） - 在里面写入：
"match_brackets": false，保存 - 回到文件，把光标移到任意括号上再移开——高亮消失，滚动恢复
这个操作只影响当前语法类型，下次打开 .log 或 .json 文件也会继承该设置。
插件干扰比设置更危险：Emmet 和 Vintage 会让括号逻辑彻底失控
如果你装了 Emmet 或 Vintage 插件，它们会劫持 {、( 等按键事件，导致 Sublime 原生的 match_brackets 和 auto_match_enabled 全部失效——不是“没生效”，而是根本没收到信号。此时你看到的“卡顿”可能是插件自身在后台做缩写展开或 vi 模式解析。
- 临时验证：终端执行
subl --safe-mode huge.log，如果秒开，问题就在插件 - Emmet 用户可在
Preferences → Package Settings → Emmet → Settings – User中加："disable_auto_insertion": true - Vintage 用户对应路径中加：
"vintage_start_in_command_mode": false
真正容易被忽略的是：match_brackets 的性能代价远高于直觉——它不显示动画、不弹提示，却在后台默默吃掉 CPU，而多数人只盯着 auto_match_enabled 反复开关，从不查它。
