sublime正则替换需注意变量命名、跨行匹配、k用法及中文编码问题：驼峰转换应避免误伤双下划线；启用“dot matches newline”或用[ss]*?处理跨行；k可精准替换不干扰上下文；utf-8文件须带bom或改用[一-龥]匹配中文。
替换所有下划线开头的变量名为驼峰式
Sublime 的正则替换能干这事，但得小心 _ 出现在单词中间或末尾的情况。直接全局搜 _([a-z]) 并替换成 U$1 会误伤 user_name → userName（对），但也可能把 __init__ → Init（错）。
实操建议：
- 先用
^[ ]*_[a-zA-Z]锁定行首单下划线 + 字母，适合处理私有变量声明 - 更稳妥的是匹配「单词边界 + 下划线 + 小写字母」：
_([a-z])，替换为U$1 - 如果要跳过双下划线（如
__dict__），加负向先行断言：(?，但注意 Sublime 的 PCRE 不支持 <code>(?，得换思路：用 <code>(? 检查前面不是字母数字 - 替换前务必勾选
Match Whole Word或手动验证上下文，Sublime 不会自动跳过注释里的下划线
跨行替换时为什么 .* 不生效
默认模式下 . 不匹配换行符，所以 function.*} 这类跨行函数体匹配会失败——它只停在第一行末尾。
实操建议：
- 打开正则面板后，点右下角
.*按钮（或按Alt+R）启用「dot matches newline」 - 或者改用
[sS]*?替代.*?，兼容性更好，且明确表达「任意字符包括换行」 - 懒惰匹配很重要：
{[sS]*?}能捕获最近的}；用*不加?会贪婪吞掉多个函数体 - 大文件慎用跨行匹配，Sublime 可能卡顿甚至崩溃，优先考虑分步：先定位函数名，再手动调整范围
用 K 丢弃匹配前缀实现精准替换
K 是 PCRE 特性，Sublime 支持，它能让正则“记住前面内容但不包含进替换范围”，比捕获组更干净。
比如要把 class="btn primary" 中的 primary 换成 danger，但不想动 class=" 和引号：
class="[^"]*Kprimary
替换为 danger 即可。没有 K 就得写 (class="[^"]*)primary 再用 $1danger，容易出错。
注意点：
-
K后面不能是环视或条件断言，只接受普通字符或简单量词 - 如果替换内容含特殊字符（如
$、），需在替换框里用\或$转义，Sublime 不自动识别字面量 - 不支持嵌套
K，一个表达式只能有一个生效点
中文路径或文件名导致正则失效怎么办
Sublime 默认用系统编码读取文件，Windows 上 UTF-8 文件若没 BOM，可能被当 GBK 解析，导致中文字符在正则里变乱码，[u4e00-u9fa5] 匹配失败。
解决方法很直接：
- 保存文件时选「File → Save with Encoding → UTF-8」，确保带 BOM（虽不推荐，但 Sublime 对无 BOM UTF-8 支持不稳定）
- 避免在正则中硬写中文，改用字符类
[一-龥]（覆盖常用汉字）或[x{4e00}-x{9fff}]（需开启 Unicode 模式，Sublime 默认开） - 如果只是想替换含中文的整行，用
^.*中文.*$更可靠，别纠结 Unicode 范围 - 批量操作前，先在小文件上试：打开文件 → Ctrl+F → 开正则 → 输入
中文看能否高亮，不行就先转编码
正则在 Sublime 里不是万能胶，它依赖底层引擎和当前文件编码状态。最常被忽略的是：你看到的「匹配成功」，可能只是编码错位下的巧合匹配。
