$1不生效是因为替换框必须用$1而非；跨行匹配需启用“. matches newline”；中文匹配失败多因编码非utf-8；所有操作前须先点find all验证。
Sublime 的正则查找替换不是“能用就行”，而是必须严格区分查找语法和替换语法、手动开关键、编码与跨行行为——关错一个开关或写错一个反斜杠，$1 就会原样输出，.* 就会卡死整行匹配。
为什么 $1 不生效，反而打出字面量 $1
这是最常踩的坑：查找时用 引用捕获组，但替换框里必须用 $1，不能写 或 \1。Sublime 在替换字段中不识别反斜杠数字引用，只认美元符号编号。
- 正确写法：查找
func(([^,]+),s*([^)]+))，替换为func($2, $1) - 错误写法：替换填
func(, )→ 输出字面量和 - 要输出字面量
$，得写$$；$会报错或不匹配 - 捕获组必须用英文小括号
()，方括号[]或花括号{}不构成分组
跨行匹配为什么 .* 总是停在第一行末尾
默认情况下，点号 . 不匹配换行符（
），所以 function.*{ 只能匹配到行尾，根本进不去函数体内部。
- 启用方式：点击替换面板右下角
.*按钮（或按Alt+R），再勾选它旁边的「.matches newline」选项（部分版本需额外点击） - 更稳写法：不用
.*?，改用[sS]*?，明确覆盖所有字符包括换行，兼容性更强 - 懒惰匹配必须加
?：写{[sS]*}会贪婪吞掉从第一个{到文件末最后一个}；应写{[sS]*?} - 大文件慎用跨行匹配：Sublime 对长文本回溯敏感，可能无响应；优先拆解：先用
^functions+w+定位函数名，再人工圈选范围
中文匹配失败，[u4e00-u9fa5] 为啥一个字都找不到
根本原因不是正则写错，而是 Sublime 读取文件时编码识别失败——UTF-8 无 BOM 的文件在 Windows 下常被当 GBK 解析，中文变乱码，正则自然失效。
- 首选方案：保存文件时选
File → Save with Encoding → UTF-8 with BOM（虽不推荐通用，但 Sublime 对它支持最稳） - 替代写法：避免硬写 Unicode 范围，改用
[一-龥]（覆盖常用汉字），或[u4e00-u9fff]（需确保文件已正确加载为 UTF-8） - 不要依赖系统 locale：即使编辑器设成中文界面，也不代表文件按 UTF-8 解码；检查右下角状态栏显示的编码格式，不是“UTF-8”就重存
- 注释里的中文也要小心：如果想跳过注释行，不能靠正则过滤，得先用
^(?!//|/*).*$手动筛选非注释行再操作
怎么安全地把 _xxx_yyy 转成驼峰，又不碰 __init__ 或 user_name_
直接搜 _([a-z]) 并替成 U$1 是危险的——它会把 __dict__ 变成 Dict__，也会把行尾下划线如 name_ 错转成 name。
- 精准锚定：用单词边界
_([a-z])，确保下划线前是空格、换行或符号，不是字母数字 - 排除双下划线：Sublime 不支持
(? 这类负向先行断言，改用 <code>(?（PCRE 风格，Sublime 支持） - 更稳妥做法：先查
^[ ]*_[a-zA-Z]锁定行首私有变量声明，再手动批量处理 - 永远先点
Find All（Alt+Enter）看匹配项列表，确认没误伤再点Replace All - 替换后检查引号/括号配对：正则不会校验语法，
"user_name"→"userName"没问题，但若中间有嵌套引号可能崩结构
真正麻烦的从来不是写对正则，而是你没法一眼看出它到底匹配了哪些隐藏位置——空格、换行、BOM、注释、引号内、缩进层级……每个都可能让 .*? 失效或 $1 落空。动手前花十秒看状态栏编码、点一次 Find All、试一个最小样本，比事后恢复快十倍。
