VSCode正则查找替换慢主因是回溯爆炸或跨行扫描失控，非引擎问题；应避免无锚点的.，改用\w+、1等限定匹配范围，并启用multiline模式、使用[\s\S]*?非贪婪匹配。) ↩
VSCode正则查找替换慢，八成不是引擎问题，而是正则写法触发了回溯爆炸或跨行扫描失控——尤其在 >2MB 的日志、模板或未格式化的 JSON 文件里。
为什么 .* 一用就卡顿甚至假死
VSCode 的 . 默认不匹配换行符，但很多人误以为 .* 能“通吃”，于是写出类似 "[^"]*" 或更危险的 ".*" 这类无锚点、无边界限制的表达式。它会让 JS 正则引擎在长文本中反复试探、回溯，直到超时或内存溢出。
- 错误写法：
function.*\{[\s\S]*?\}—— 开头没限定函数名长度，.*先贪婪吞掉大段内容，再倒退匹配{，极易卡住 - 安全替代：
function\s+\w+\s*$$[^)]*$$\s*\{[\s\S]*?\}，用\w+锁定函数名，[^)]*代替.*防止跨参数乱吃 - 大文件处理前，先用
Ctrl+Shift+P → Change End of Line Sequence统一为 LF，避免 CRLF 混用加剧回溯
^ 和 $ 在多行模式下为何不生效
很多人写 ^\s*$ 想删空行，却只删掉文件开头或结尾的空白——因为默认模式下 ^ 和 $ 只匹配整个文档首尾，不是每行。必须同时满足两个条件才真正按行工作：
- 点击查找框右侧的
.*图标（启用正则） - 再点击旁边的
\n图标（tooltip 显示 “Match newline characters”），这个开关才开启 multiline 模式 - 若仍无效，检查是否启用了
files.exclude或search.exclude，某些被排除的文件类型（如.log）可能被跳过，导致“搜不到”错觉
捕获组嵌套太多导致性能骤降
VSCode 支持最多 9 层捕获组，但每多一层括号，引擎就要维护额外状态。像 ((a)(b(c(d)))) 这种结构，在千行级 JSX 或 HTML 中会显著拖慢匹配速度。
- 优先用非捕获组：
(?:...)替代(...)，避免编号膨胀和状态开销 - 想提取引号内内容？用
"([^"]*)"而不是"(.*)"，前者明确终止于下一个"，后者可能一路吃到文件末尾 - 不确定要不要分组？先用
$&引用整个匹配项做测试，确认范围后再拆细
跨行匹配时 [\s\S]*? 比 .* 更可靠
VSCode 不支持 /s（dotAll）标志，所以 .* 永远不匹配换行。有人试 [\s\S]* 却发现还是慢——问题出在 * 是贪婪的，[\s\S]* 会先吞光所有内容，再一点点吐出来找结尾。
- 必须加
?：写成[\s\S]*?，让匹配变成非贪婪，遇到第一个符合条件的结束符就停 - 匹配 JSDoc：
/\*\*[\s\S]*?\*/；匹配带换行的字符串："[\s\S]*?" - 性能敏感场景下，尽量前置锚点，比如
console\.log$$[\s\S]*?$$比[\s\S]*?console\.log$$[\s\S]*?$$快一个数量级
真正影响速度的从来不是正则功能本身，而是你有没有在写的时候，就想到它会在 10 万行文件里执行多少次回溯。每次敲 .* 前，先问一句：它到底该吃到哪儿？
