正则替换前必须勾选“in selection”以限制作用范围，否则默认全文匹配；$0引用整个匹配串，$1引用首个捕获组；非utf-8文件需重载编码或避免正则；alt+f3不适用于结构化文本，应分步定位字段。
正则替换前必须确认“In Selection”是否启用
Ctrl+Shift+L 拆出多行光标后，直接 Ctrl+H 打开替换面板并启用正则，Alt+Enter 仍不会只在光标所在行生效——因为 Sublime 默认忽略光标位置，仍在全文档匹配。关键动作是：在查找面板右下角手动勾选 In Selection（小勾图标），否则所有正则操作都脱离控制。
常见错误现象：
- 本想只改第2列的邮箱，结果把注释里的邮箱也替了
- 日志中某几行没匹配上，
Alt+Enter后光标数量变少，后续编辑错位
建议流程：Ctrl+Shift+L → Ctrl+F → 勾选 In Selection → Alt+R 开正则 → 输入模式 → Alt+Enter 生成光标
捕获组引用 $1、$0 的实际行为差异
正则中用 () 包住的内容会生成捕获组，$1 引用第一个括号内容，$0 引用整个匹配串。但它们在不同场景下效果不同：
- 查找
"url":\s*"([^"]*)"，替换为"url": $1→ 正确提取引号内路径 - 查找
\d+，替换为id_$0→ 给所有数字加前缀，不需括号 - 若写成
(\d+)再用$1，和$0效果一致；但多组时顺序敏感，$2必须对应第二个()
注意：$0 在部分旧版 Sublime 中兼容性略差，优先用 $1 显式捕获更稳妥
非 UTF-8 文件里正则容易截断中文
GBK 或 GB2312 编码的文件中，正则引擎可能把一个中文字符误判为两个字节，导致 . 匹配异常、\s 错位、甚至替换后乱码。这不是正则写错了，而是编码层解析失败。
解决办法只有两个：
- 先用
File → Reopen with Encoding → UTF-8重载文件（如果内容可安全转码） - 或彻底避免在非 UTF-8 文件中启用正则，改用纯文本查找 +
Ctrl+D逐个处理
临时判断方式：在查找框输入 [\u4e00-\u9fa5]，若无高亮，基本可确认当前编码不被正则支持
Alt+F3 全局匹配不适合表格/日志类结构化文本
Alt+F3 是全文档级正则匹配，适合变量重命名这类语义一致的场景；但面对日志、CSV、JSON 行结构不一的文本时，它无法区分“同一字符串在不同列的含义”。比如 user 出现在时间列和用户名列，Alt+F3 会一并选中。
真正可控的做法是分步隔离：
- 先用正则精准定位目标字段，例如日志中提取 IP：
\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} -
Ctrl+H+Alt+Enter选中所有 IP →Ctrl+Shift+L拆光标 - 用
Ctrl+←/Ctrl+→跳到字段内部，再删除或输入
这比强行用 ^.*?(\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}).*$ 加锚点更可靠——因为真实日志常有缩进不齐、空字段、换行嵌套等问题，锚点反而失效
