sublime text正则分组替换必须同时满足三条件：启用正则（.*图标变蓝且状态栏显示regex）、括号成对且按左括号顺序编号、替换用$1而非\1；缺一则$1原样输出。
Sublime Text 的正则替换不是“写对表达式就自动生效”，它必须满足三个硬性前提：正则模式已启用、括号被正确识别为捕获组、替换语法用 $1 而非 \1——缺一不可，否则 $1 会原样输出，而不是提取内容。
为什么 $1 总是变成字面量，而不是实际匹配内容
根本原因不是正则写错了，而是查找面板右下角的 .* 图标没点亮，或者状态栏没显示 Regex。Sublime 只有在正则模式激活时才把 (\w+) 解析为捕获组；否则它就当普通括号处理，(\w+) 实际匹配的是字面的 (w+)。
- 务必点击替换面板右下角的
.*图标（或按Alt+R），让它变蓝 - 检查右下角状态栏是否显示
Regex，没显示就说明没生效 - 查找内容里如果真要匹配字面括号（比如
func(x)中的()），必须写成\(和\)，否则会被当成捕获组 - 替换框里写
$1是唯一推荐写法；\1在新版 Sublime 中不被支持，${1}虽部分可用但不保证跨版本兼容
$1 编号怎么数？嵌套和非捕获组怎么影响顺序
Sublime 按左括号 ( 出现的**从左到右顺序**编号，不管嵌套深度。它不支持 (?:) 非捕获组，所有 ( 都占编号位——这点和 Python/JS 不同，极易误判。
-
(a(b(c)))中：$1 = abc，$2 = bc，$3 = c -
(a(b)(c))中：$1 = abc，$2 = b，$3 = c（没有非捕获组，所有括号都计数） -
$0始终代表整个匹配结果，不是第一组；别用它替代$1 - 如果替换后为空或乱码，先检查编号是否超出实际括号对数（比如写了
$3但只有一对()）
跨行匹配时 .* 为什么总卡住或吞太多
默认 . 不匹配换行符，强行开启 . matches newline 后，.* 会贪婪吞到文件末尾，尤其遇到嵌套结构（如 {{}}）极易回溯爆炸。
- 优先用
[\s\S]*?替代.*?：明确覆盖所有字符，Sublime 解析更稳 - 匹配大括号体时，写
\{[\s\S]*?\}，别用\{.*?\}（即使开了. matches newline也不可靠） - 函数参数提取慎用
.*?，改用否定字符集：\(([^)]+)\)更安全；含换行时再加[\s\S]，如\(([\s\S]*?)\) - 大文件（>5MB）避免跨行正则批量替换，先用
Find in Files定位范围，再人工分块操作
中文匹配失败，[\u4e00-\u9fa5] 一个字都找不到
不是正则写错，是 Sublime 加载文件时编码识别失败——UTF-8 无 BOM 的文件在 Windows 下常被当 GBK 解析，中文已乱码，正则自然无效。
- 看右下角状态栏显示的编码：如果不是
UTF-8，就执行File → Save with Encoding → UTF-8 with BOM（最稳方案） - 避免硬写 Unicode 范围，改用
[一-龥]（覆盖常用汉字），或确保文件已正确加载为 UTF-8 后再用[\u4e00-\u9fff] - 中文文本中混用全角/半角空格、制表符时，
[ \t]会漏掉全角空格，需显式加上\s并确认其行为
真正卡住的地方往往不在正则本身，而在编码、括号计数、跨行开关这三个开关是否全部打开——它们之间没有容错，任何一个关着，$1 就只是五个字符。
