必须掌握核心元字符（^$.*+?{}[]|()）及其转义规则，[ ]内多数元字符无需转义但^、-、]、例外；注意dws跨引擎差异；量词默认贪婪，需加?变懒惰；优先用非捕获组(?:)提升性能；不同工具正则引擎特性各异，使用前须确认环境。
正则表达式里那些必须掌握的元字符和转义规则
写正则时最常卡壳的地方，不是逻辑，而是某个字符没加反斜杠却想让它字面匹配——比如想匹配 . 却忘了写成 .，结果它成了“匹配任意字符”的通配符。这类问题几乎占日常调试的一半。
核心元字符包括：^ $ . * + ? { } [ ] | ( )，它们在正则上下文中自带特殊含义。只要你想让它们表示自己本身（比如匹配一个实际的 + 号），就必须用 + 转义。
-
[ ]内部大部分元字符自动失效（如+、*不需转义），但^（开头否定）、-（范围连接）、]（结束标记）、（仍需转义）例外 -
d、w、s是预定义字符类，比手写[0-9]更简洁，但注意w在不同引擎中可能包含下划线或 Unicode 字母（如 Python 默认含中文，JS 不含） - 在字符串字面量中写正则时（如 JavaScript 的
new RegExp("a\+b")），反斜杠要双写：第一个用于 JS 字符串转义，第二个才传给正则引擎
量词的贪婪 vs 懒惰：为什么 .* 总是吃掉太多
.* 看似简单，却是捕获内容错位的头号原因。它默认贪婪，会尽可能往右吞，直到无法匹配为止。比如从 "start<a>text</a>end" 中提取 <a>...</a>，用 <a>.*</a> 会直接匹配到末尾的 </a>，而不是第一个闭合标签。
解决方法就是加 ? 切换为懒惰模式：<a>.*?</a>。此时它会“能少匹配就少匹配”，遇到第一个 </a> 就停。
- 所有量词都支持懒惰写法：
*?、+?、??、{n,m}? - 懒惰不等于“最短匹配”——它只保证局部最小，不保证全局最优；复杂嵌套仍可能出错（此时应改用否定字符类，如
<a>[^<]*</a>） - 性能上，懒惰量词可能回溯更多次，尤其在长文本中；若结构明确，优先用
[^x]*替代.*?
捕获组与非捕获组的实际取舍
写 (d{4})-(d{2})-(d{2}) 很自然，但如果你只是想分组并复用（比如后面用 引用），而不需要提取每段年月日，那三个括号全是冗余捕获，拖慢性能还占内存。
这时候该用非捕获组：(?:d{4})-(?:d{2})-(?:d{2})。它只分组、不保存匹配内容，正则引擎不会为它分配捕获编号。
- 命名捕获组（如 Python 的
(?P<year>d{4})或 JS 的(?<year>d{4})</year>）可读性高，但旧版环境（如 IE、某些嵌入式 JS 引擎）不支持 - 反向引用必须用捕获组，非捕获组不能被
或$1引用 - 替换操作中若只用整个匹配（
$&或&），而非子组，就完全没必要开捕获
不同语言/工具里的正则差异点
同一个正则，在 Python re、JavaScript、grep、sed 甚至 VS Code 查找框里，行为可能不同——不是语法错，是引擎实现或默认标志不一致。
比如行首锚定：^ 在多行模式下是否匹配每行开头？Python 默认不开启 re.MULTILINE，JS 需显式加 m 标志，而 grep -E 默认就是逐行处理，^ 天然生效。
- JS 不支持
A和Z（字符串绝对首尾），只认^/$+m标志 - Python 的
re.sub()中，替换字符串里用引用捕获组；而 JS 用$1，且$&表示整个匹配 - VS Code 查找框默认启用
g（全局）和m（多行），但不支持 lookbehind（如(?<=abc)def）除非开启实验性选项 - PostgreSQL 的
~操作符使用 POSIX ERE，不支持d，得写[0-9]
真正麻烦的不是学语法，而是每次粘贴正则前，先确认当前环境用的是什么引擎、开了哪些标志、哪些特性被禁用——漏看这一条，就足以让一个本该工作的正则彻底失效。
