sublime text正则分组替换必须同时满足三条件：启用正则模式（.*图标变蓝且状态栏显示regex）、括号成对且按左括号顺序编号、替换用$1而非或${1}；否则$1原样输出。
Sublime Text 的正则替换不是“写对就能用”，而是必须同时满足：正则模式已启用、括号成对且编号正确、替换语法用 $1 而非 或 ${1}——缺一不可，否则 $1 会原样输出。
为什么 $1 总是变成字面量，而不是实际内容
根本原因不是正则写错了，而是 .* 图标没点亮，或者括号被当成了普通字符处理。
- 务必点击替换面板右下角的
.*图标（或按Alt+R），让它变蓝 - 检查右下角状态栏是否显示
Regex，没显示就说明没生效 - 查找内容里有真实括号（比如想匹配
func(x)中的()），必须写成(和)，否则会被误认为捕获组 - 替换框里写
$1是唯一稳定写法；在新版 Sublime 里不支持，${1}部分版本能解析但不推荐依赖 - 如果替换了 0 处，先看右下角是不是
.*，再检查表达式是否含未转义的特殊字符（如.想匹配字面点号却没写成.）
跨行匹配时 .* 为啥总卡住或吞太多
默认 . 不匹配换行符，强行开启 . matches newline 后，.* 会贪婪吞到文件末尾，尤其遇到嵌套结构（如 {{}}）极易回溯爆炸。
- 优先用
[sS]*?替代.*?：明确覆盖所有字符，兼容性更好，Sublime 解析更稳 - 匹配大括号体时，写
{[sS]*?}，别用{.*?}（即使开了. matches newline也不可靠） - 函数参数提取慎用
.*?，改用否定字符集：(([^)]+))更安全；含换行时再加[sS]，如(([sS]*?)) - 大文件（>5MB）避免跨行正则批量替换，先用
Find in Files定位范围，再人工分块操作
中文匹配失败，[u4e00-u9fa5] 一个字都找不到
不是正则写错，是 Sublime 加载文件时编码识别失败——UTF-8 无 BOM 的文件在 Windows 下常被当 GBK 解析，中文已乱码，正则自然无效。
- 看右下角状态栏显示的编码：如果不是
UTF-8，就File → Save with Encoding → UTF-8 with BOM（最稳方案） - 避免硬写 Unicode 范围，改用
[一-龥]（覆盖常用汉字），或确保文件本身带 BOM -
w默认只匹配 ASCII 字母数字下划线，不包含汉字；要匹配中文请用[一-龥]或(?u)p{Han}（需开启 Unicode 模式） - 中文路径或文件名导致正则失效？本质仍是编码问题，统一保存为 UTF-8 with BOM 即可解决
用 K 精准替换前缀而不干扰上下文
K 是 PCRE 特性，Sublime 支持，它能让正则“记住前面内容但不包含进替换范围”，比捕获组更干净。
- 比如要把
class="btn primary"中的primary换成danger，但不想动class="和引号：class="[^"]*Kprimary替换为danger即可 - 没有
K就得写(class="[^"]*)primary再用$1danger，容易出错 -
K后面不能是环视或条件断言，只接受普通字符或简单量词 - 不支持嵌套
K，一个表达式只能有一个生效点 - 替换内容含特殊字符（如
$、）需在替换框里用$或\转义，Sublime 不自动识别字面量
真正卡住人的往往不是语法多难，而是模式没开、括号没闭合、$1 写成 这种低级但极难自查的细节——每次替换前，先用 Find 功能验证正则是否真能命中目标文本，再点 Replace All。
