根本原因是贪婪匹配引发回溯爆炸，尤其在含node_modules等大文件夹时；应限定搜索路径、避免.*、用非贪婪量词、指定文件类型、开启替换正则开关，并处理中文空白符。
为什么跨文件正则搜索会卡顿甚至无响应
根本原因是 (?s) 或 .* 类贪婪匹配在大项目中极易引发回溯爆炸，尤其当目标文件夹包含 node_modules、dist/ 或压缩 JS 时，Sublime 会逐字节尝试所有可能路径。这不是内存不足，而是 PCRE 引擎在做指数级状态匹配。
实操建议：
- 永远在全局搜索（
Ctrl+Shift+F）的Where框里加路径过滤，例如src/**/*.js或!**/node_modules/**，别依赖正则自己“跳过” - 避免用
.*匹配任意内容，改用更窄的字符类：比如想匹配字符串字面量，用"[^"\\n]*"而不是".*?" - 若必须跨行，优先用
(?s)console.log((.*?))而非(?s)console.log((.*))，非贪婪能显著减少回溯深度 - 对超大日志文件（>50MB），先用
Ctrl+P单独打开，再用Ctrl+F局部查找——Sublime 的懒加载只对单文件生效
如何避免 ^ 和 $ 拖慢搜索速度
^ 和 $ 在 Sublime 中默认是「多行模式」，即每行都算一次锚点。但当你在 Where 里没限定文件类型，它就会把 Markdown 表格、JSON 注释、HTML 标签全当“行”来扫，导致大量无效判断。
实操建议：
- 明确指定文件后缀：
file:*.ts,*.js，比file:*快 3–5 倍 - 不用
^functions+w+查函数定义，改用^s*(asyncs+)?functions+(w+)，显式跳过缩进和async，减少分支猜测 - Windows 换行符
$多一次判断，统一换行格式为 Unix (LF) 后，性能提升约 12% - 如果只是找行首关键词，直接用
^keyword即可；想排除注释行，写成^[^/ ]*keyword，比^(?!//).*keyword更轻量
替换时 $1 不生效却以为正则失败？其实是开关没开两次
查找面板和替换面板的正则开关是独立的。你在查找框点了 .* 图标，不代表替换框也启用了——这是 90% 用户卡住的第一步。
实操建议：
-
Ctrl+H打开替换面板后，必须手动点击右下角.*图标（或按Alt+R），图标变蓝才算真正启用 -
$1只支持前 9 个捕获组，$10会被当作字面量$1+0输出，别写超过 9 对括号 - 测试分组是否有效：先用
Find All（Alt+Enter）看高亮范围是否符合预期，再点Replace All - 要输出真实美元符号，写成
$$，例如cost: $$100→cost: $100
中文混排文本里正则失效的隐蔽原因
不是正则写错了，是 s 根本不认全角空格（U+3000）、不间断空格（U+00A0）和零宽空格（U+200B）。你在中文文档里搜 key:s+value，永远匹配不到带全角空格的那行。
实操建议：
- 查全角空格：直接复制一个进查找框，或写
u3000 - 清理混合空白：用
[ u3000u00A0u2000-u200Bu2028u2029]+替换为单个半角空格 - 中文界面插件可能干扰换行符识别，临时切语法为
Plain Text（Ctrl+Shift+P→Set Syntax: Plain Text）再试 - 邮箱、手机号等字段提取，别依赖
，它在中文前后不可靠；改用(? 和 <code>(?=[^a-zA-Z0-9]|$)显式断言边界
最常被忽略的一点：Sublime 的正则性能瓶颈几乎从不来自表达式本身，而来自搜索范围失控。哪怕正则再精巧，Where 框里漏写一个 ! 排除 node_modules，就足以让整个搜索卡死在某个 2MB 的 min.js 里——它不会报错，只会静默卡住。
