sublime中正则匹配数字加特定字符需防误伤：\d仅匹配ascii数字且依赖utf-8编码，推荐用[0-9]；匹配user_456需负向断言控制边界；price$789中$须转义为\$，并注意上下文避免误改。
Sublime 里用正则匹配数字加特定字符（比如 id123、user_456、price$789），关键不在“怎么写”，而在“怎么防误伤”——\d 和 [0-9] 看似等价，但搭配不同边界或上下文时，行为差异极大，尤其在混合中英文、带 Unicode 符号或嵌套结构的代码里。
为什么 \d 在 Sublime 里有时不匹配数字？
Sublime 默认用 Boost.Regex 引擎，\d 只匹配 ASCII 数字 0–9，对全角数字（如「１２３」）、带变音符号的数字（极少见）或某些 UTF-8 编码异常的文件完全失效。更常见的是：文件编码不是 UTF-8（比如被识别为 Latin-1），导致 \d 查不到任何东西。
- 先确认状态栏右下角显示
UTF-8；如果不是，菜单 →File → Reopen with Encoding → UTF-8 - 保险起见，直接用
[0-9]替代\d，语义明确、跨编码稳定 - 若需兼容全角数字，得显式写
[0-9\uff10-\uff19]（但极少需要，且易出错）
user_456 这类含下划线+数字的组合怎么精准抓？
目标是只匹配 user_456，不命中 user_name（无数字）、users_4567（多一位）或 my_user_123（前面多词）。不能靠 \w+_\d+——它太宽泛，会切开长变量名。
- 用负向断言控制左右边界：
(? —— 确保前后都不是字母/数字/下划线 - 如果下划线是可选的（如
id123或id_456），改用：(? - 避免
\b：它在user_name中把_当作边界，导致\buser_\d{3}\b匹配失败 - 测试时点
Find All，看高亮是否恰好卡在完整 token 上，而不是切进字符串或注释里
匹配 price$789 这种带特殊符号的组合要注意什么？
$ 是正则元字符，代表行尾，不转义就根本不会去匹配字面量 $。类似还有 +、*、?、(、) 等——它们在正则模式下必须加反斜杠才能当普通字符用。
- 正确写法：
price\$\d{3}（注意\$） - 如果符号本身是变量（比如要批量处理
total@123、count#456），用字符组：total[@#]\d{3} - 想确保
$后面紧跟着数字（不能是空格或字母），加正向先行断言：price\$(?=\d{3}(?!\w))，再配合替换逻辑 - 全局替换前，务必手动检查几处高亮：是否落在 JSON 字符串内（如
"price":"$789"）、HTML 属性值或正则字面量（如/price\$\d+/）中——这些地方不该动
真正难的不是写出能跑的正则，而是判断它在哪种上下文中会悄悄漏掉一个 id123，又在哪种文件编码里突然多匹配出三个乱码数字。每次点 Replace All 前，三秒停顿：看一眼 .* 图标是否亮着、Where 路径有没有误含 node_modules、Find All 预览里第一项是不是你真想改的地方。
