BracketHighlighter在百万行文件中悬停卡顿是因默认全局括号匹配引发正则回溯，解决方法包括启用视口限制、关闭冗余扫描、设置max_file_size为10MB，并调优主题中meta.brace样式。
为什么BracketHighlighter在百万行文件里一悬停就卡住
不是插件太老，是它默认对整文件做括号匹配扫描——尤其遇到JSON.stringify(obj)这种单行长嵌套、或压缩JS里连续几十层{[()]}时，正则回溯直接吃满一个CPU核。ST4的渲染管线虽快，但插件仍走旧式region绘制路径，每帧都要重算匹配位置。
关键点：卡顿和高亮错位往往同时出现，说明问题不在主题样式，而在匹配引擎本身没做范围裁剪。
- 确认是否真由BracketHighlighter引起：命令行启动
subl --safe-mode huge.json，若悬停不卡，基本锁定插件 - 检查插件版本：必须用
BracketHighlighter（首字母大写），不是已停止维护的BracketHighlighter（全小写） - 禁用“高亮内容”类选项：
"highlight_content": false和"highlight_scope": false能砍掉70%计算量
如何让括号高亮只扫当前视口而非全文
原生match_brackets只作用于光标邻近区域，但BracketHighlighter默认全局扫描。必须手动限制作用域，否则滚动时它还在后台疯狂匹配上万行外的括号。
打开Preferences → Package Settings → BracketHighlighter → Bracket Highlighter Settings，重点改这三项：
-
"scan_regions": ["bracket"]—— 只启用括号匹配，关掉引号、标签等冗余扫描 -
"ignore_string_escape": true—— 避免在字符串里误判\{为真实括号，减少无效回溯 -
"max_file_size": 10—— 单位MB，超过此大小自动降级为原生match_brackets，不加载插件逻辑
注意："max_file_size"设为10而非0，否则插件会彻底失效；设为100则失去保护意义。
ST4原生匹配在长行里为何失效
原生Ctrl+M跳转和match_brackets高亮，在单行超2000字符时大概率失灵——不是bug，是ST4为防正则爆炸主动截断扫描长度。你光标明明停在{上，却没反应，十有八九是这行太长被跳过了。
验证方法：打开控制台(Ctrl+`)，输入view.settings().get('max_line_length')，默认值通常是10000，但实际生效阈值低得多。
- 临时解法：按
Ctrl+Shift+P→ 输入View: Toggle Word Wrap强制换行，把长行切成多行再操作 - 根治办法：在用户设置里加
"max_line_length": 50000（别设0，会崩溃），但仅对新打开文件生效 - 更稳方案：对日志/压缩文件，右下角点语法名 →
Open all with current extension as… → Plain Text，原生匹配立刻恢复
高亮颜色太淡或错位？先查主题里的meta.brace scope
BracketHighlighter和原生匹配都依赖主题定义的meta.brace样式。很多自定义主题删掉了这项，或设了opacity: 0.3，导致高亮像一层灰雾。
定位方式：用PackageResourceViewer打开当前主题文件，搜索meta.brace或bracket，重点看这两处：
- 是否存在
"scope": "meta.brace"—— 缺失则高亮完全不显示 -
"foreground"值是否为有效十六进制，如"#FF5555"；避免写成"red"或"#f55"（ST4不兼容简写） - 若有
"background"字段，确保不是"#00000000"（全透明），否则高亮框看不见
改完保存，不用重启，高亮立刻刷新。如果仍错位，大概率是括号嵌套过深（>15层）触发了ST4的渲染保护机制，此时换用ScopeHunter插件查scope链比调颜色更有效。
