$1被当字面量输出的根本原因是未同时满足三个条件：.*图标未点亮、状态栏未显示regex、替换框误用\1或${1}；sublime仅在正则模式激活时解析捕获组，否则(w+)匹配字面(w+)。
为什么$1总被当字面量输出
根本原因不是正则写错了，而是三个硬性条件没同时满足：.*图标没点亮、状态栏没显示Regex、替换框写了或${1}。Sublime 只在正则模式激活时才把(w+)解析为捕获组；否则(w+)就匹配字面的(w+)。
务必点击替换面板右下角的.*图标（或按Alt+R），让它变蓝；检查右下角状态栏是否显示Regex；查找内容里真要匹配字面括号（比如func(x)中的()），必须写成(和)；替换框里只认$1，不支持，${1}部分版本能解析但不稳定。
$1编号严格按左括号从左到右顺序计数，不管嵌套深度：(a(b(c)))中$1 = abc、$2 = bc、$3 = c；Sublime 不支持(?:)非捕获组，所有(都占编号位。
跨行匹配总卡住或吞太多
.默认不匹配换行符，这是硬限制。强行开启. matches newline后，.*?又容易贪婪回溯爆炸——尤其遇到{{}}这类嵌套结构时，可能直接吞到文件末尾。
稳妥做法是放弃.*?，改用显式字符集：[sS]*?明确覆盖所有字符（含换行），兼容性更好；匹配大括号体写{[sS]*?}，别用{.*?}；提取函数参数含换行时用(([sS]*?))，比(([^)]*))更安全。
大文件（>5MB）避免直接跨行正则批量替换：先用Find in Files（Ctrl+Shift+F）定位范围，再人工分块操作；启用. matches newline后若卡死，说明文本含零宽字符或混合编码，先清空白再试。
中文匹配失败或乱码
不是正则写错，是 Sublime 加载文件时编码识别失败——UTF-8 无 BOM 的文件在 Windows 下常被当 GBK 解析，中文已乱码，正则自然无效。
看右下角状态栏显示的编码：如果不是UTF-8，就执行File → Save with Encoding → UTF-8 with BOM（最稳方案）；避免硬写[u4e00-u9fa5]，改用[一-龥]（覆盖常用汉字）；在 Sublime 中把_和数字也当单词字符，匹配user时可能命中username，简单场景直接加空格或冒号限定，如 user 或user:。
中文路径或文件名导致正则失效？本质仍是编码问题，统一保存为UTF-8 with BOM即可解决；w默认只匹配 ASCII 字母数字下划线，不包含汉字，要匹配中文请用[一-龥]或(?u)p{Han}（需确保文件已正确加载为 UTF-8）。
删空行、去重、重命名这些高频操作怎么不出错
看似简单的需求，一用错正则就漏删、误删、卡死——根本原因是没区分「整行」和「逻辑块」的语义边界。
删空行：用^[ ]*$，别用^s*$（s匹配
，可能破坏上下文）；保序去重（如清理 import 列表）：先统一换行符为 Unix（File → Line Endings → Unix），再用^(.*$)
(?=.*^$)配合. matches newline；提取括号参数：单层用(([^)]+))，含换行用{[sS]*?}，嵌套如fn(a, fn(b))不支持递归，须分步或人工校验。
重命名变量：想把user_name→userName，用([a-z]+)_([a-z])([a-z]*)→$1u$2$3；但__init__无法用负向断言跳过，得人工复查结果；批量操作前必先点Find All确认能命中目标——这一步省掉，后面全是白忙活。
