sublime正则匹配卡顿源于整文件贪婪回溯与高亮渲染，需关实时高亮、限搜索范围、禁回溯优化项；关键配置包括"index_files": false、"detect_indentation": false等。
Sublime 的正则匹配卡顿，不是正则写得不够“高级”，而是它默认对整文件做贪婪回溯 + 高亮渲染——哪怕只搜 ^\d+，遇到百万行日志也卡死。关掉实时高亮、限制作用域、禁用回溯优化项，三步就能让搜索从“等半分钟”变成“秒出结果”。
为什么 Find 对话框一输正则就卡？
Sublime 在 Find 模式下默认开启三项高开销行为：实时高亮所有匹配项（含未展开的折叠块）、对整文件做完整回溯扫描、尝试为每个匹配生成语法上下文（比如判断是否在字符串内）。对大文件而言，这三项加起来比 grep 慢两个数量级。
-
Find输入框里每敲一个字符，它都在后台跑一次全量匹配 + 渲染 - 启用
Regex但没关Highlight matches，会导致滚动时反复重绘数千个高亮矩形 - 正则中用了
.*或\s+这类无锚定的量词，Sublime 会从头开始暴力回溯，CPU 直接拉满
怎么让 Find in Files 不扫完整个 500MB 日志？
别依赖默认的“当前项目”或“打开的文件”，主动切到最小作用域再执行搜索——Sublime 的 Find in Files 本身不慢，慢在你让它扫了不该扫的路径。
- 先用
Ctrl+Shift+F（Win/Linux）或Cmd+Shift+F（macOS）打开面板 - 在
Where栏手动填入具体路径，例如：/var/log/app.log，而不是留空或填./ - 勾选
File name filter并填app.log，避免它顺手把同目录下其他 .json/.tmp 文件也拖进来 - 取消勾选
Regular expression下方的Highlight matches—— 这个开关独立于主界面，必须手动关
regex 匹配时 CPU 拉满，该禁用哪些设置？
关键不是改正则本身，而是让 Sublime 别对匹配过程做“过度服务”。以下配置加进 Preferences → Settings – User，能切断大部分隐式开销：
-
"find_selected_text": false—— 防止光标选中一段后自动把那段当搜索词，意外触发长匹配 -
"highlight_modified_tabs": false—— 修改 tab 标题高亮和正则无关，但会干扰渲染队列 -
"index_files": false—— 后台索引进程常和正则扫描抢资源，尤其在Find in Files启动瞬间 -
"detect_indentation": false—— 对纯日志类文本，它仍会为每行检查缩进以决定折叠逻辑，徒增扫描负担
注意："large_file_size_limit": 100 对正则搜索无效——它只影响文件加载阶段，不影响已打开文件的查找行为。
真正卡住时，怎么 5 秒内恢复响应？
别关窗口、别重启，直接中断正在运行的匹配任务链：
- 按
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（macOS），输入Cancel Find回车——这是 Sublime 唯一暴露的“终止搜索”命令 - 如果命令面板无响应，立刻终端执行：
subl --safe-mode your_file.log，然后重开Find面板 - 临时切换语法：
Set Syntax: Plain Text，避免正则引擎还要解析当前语法定义里的嵌套规则（比如 JSON 中的字符串转义）
最易被忽略的一点：Sublime 的正则引擎不支持 JIT 编译，所有 .*? 类模式都走回溯，哪怕加了 ^ 或 $ 锚点，只要没配合 \A/\Z，它仍可能从中间某行开始瞎试——这不是 bug，是设计如此。
