BracketHighlighter 在大文件中因默认悬停全行正则匹配引发灾难性回溯导致UI冻结，需手动禁用或关闭 bracket_contents、find_in_open_files、ignore_syntaxes 等高耗设置。
BracketHighlighter 在大文件里正则回溯卡死
不是括号高亮功能本身有问题，而是 BracketHighlighter 插件默认开启光标悬停即全行正则匹配，在长日志行（比如 10KB+ 的单行 JSONL）里会触发灾难性回溯，UI 直接冻结。这不是 Sublime 崩溃，是插件在后台死循环。
临时验证是否是它导致：命令行运行 subl --safe-mode huge.log，如果秒开可滚动，问题就出在插件；再单独禁用 BracketHighlighter 即可确认。
- 别等它自己“适应”——大文件下它不会降级策略，必须手动干预
- 禁用方式：Preferences → Package Control → Disable Package →
BracketHighlighter - 若必须保留高亮，改配置项
"high_visibility_enabled": false（关常驻高亮），只保留悬停触发，且确保"bracket_contents": false（不匹配括号内内容，减少扫描范围）
Plain Text 模式下括号高亮本就不该存在
设为 Plain Text 后，Sublime 不加载任何语法 scope，BracketHighlighter 失去匹配依据，根本不会尝试高亮——这反而是正确行为。很多人误以为“高亮没了=坏了”，其实是它按设计退出了。
常见错误现象：日志文件点右下角选了 Plain Text，但还期待 {} 被描边，结果没反应，于是反复重装插件、调配置，白忙活。
- 想让括号有响应，必须先让 Sublime 认出这是什么语言：按
Ctrl+Shift+P→ 输入Set Syntax: JSON或Set Syntax: Log - 但注意：
Log语法包自带大量行级正则，50MB 日志里一启用就卡死，比Plain Text还危险 - 真正安全的折中：用
Set Syntax: JSON+ 关闭BracketHighlighter的bracket_contents和high_visibility_enabled
大文件里开括号高亮前必须关掉的三项设置
即使你坚持要用 BracketHighlighter 查看某段代码块，也得先砍掉它最耗资源的三个行为，否则刚滚动就卡住。
打开 Preferences → Package Settings → BracketHighlighter → Bracket Highlighter Settings，确保以下三项明确设为 false：
-
"bracket_contents": false—— 不扫描括号内部，避免整行字符串遍历 -
"find_in_open_files": false—— 不跨文件搜索匹配项，防止后台扫整个项目 -
"ignore_syntaxes": ["Plain Text", "Log"]—— 显式排除已知高危语法类型，防误触发
顺手在 Sublime 全局设置里加 "highlight_line": false，否则光标一停在括号行，highlight_line 和 BracketHighlighter 双重渲染，CPU 瞬间拉满。
比高亮更重要的：用外部命令定位括号结构
真正在查大日志里的 JSON 块或 XML 片段时，靠 Sublime 高亮翻找效率极低——它连 { 和 } 是否成对都可能算错，因为不完整加载或换行截断。
直接用命令行筛出目标块更可靠：
- 查某段 JSON：
grep -A 20 -B 5 '"error":' app.log | head -n 50 > snippet.json - 提取从第 1000 行起第一个
{到对应}：用awk脚本或jq -r 'select(.level=="error")' app.jsonl - 把提取结果存为小文件再用 Sublime 打开，此时开
BracketHighlighter完全无压力
记住：括号高亮是编辑器锦上添花的功能，不是日志分析的基础设施。越依赖它处理大文件，越容易陷入“调参半天，不如 grep 三秒”的循环。
