正则表达式主要包括_正则表达式核心语法成分构成

必须掌握核心元字符（^$.*+?{}[]|()）及其转义规则，[ ]内多数元字符无需转义但^、-、]、\例外；注意\d\w\s跨引擎差异；量词默认贪婪，需加?变懒惰；优先用非捕获组(?:)提升性能；不同工具正则引擎特性各异，使用前须确认环境。

正则表达式里那些必须掌握的元字符和转义规则

写正则时最常卡壳的地方，不是逻辑，而是某个字符没加反斜杠却想让它字面匹配——比如想匹配 . 却忘了写成 \.，结果它成了“匹配任意字符”的通配符。这类问题几乎占日常调试的一半。

核心元字符包括：^ $ . * + ? { } [ ] \ | ( )，它们在正则上下文中自带特殊含义。只要你想让它们表示自己本身（比如匹配一个实际的 + 号），就必须用 \+ 转义。

• [ ] 内部大部分元字符自动失效（如 +、* 不需转义），但 ^（开头否定）、-（范围连接）、]（结束标记）、\（仍需转义）例外
• \d、\w、\s 是预定义字符类，比手写 [0-9] 更简洁，但注意 \w 在不同引擎中可能包含下划线或 Unicode 字母（如 Python 默认含中文，JS 不含）
• 在字符串字面量中写正则时（如 JavaScript 的 new RegExp("a\\+b")），反斜杠要双写：第一个用于 JS 字符串转义，第二个才传给正则引擎

量词的贪婪 vs 懒惰：为什么 .* 总是吃掉太多

.* 看似简单，却是捕获内容错位的头号原因。它默认贪婪，会尽可能往右吞，直到无法匹配为止。比如从 "starttextend" 中提取 ...，用 .* 会直接匹配到末尾的 ，而不是第一个闭合标签。

解决方法就是加 ? 切换为懒惰模式：.*?。此时它会“能少匹配就少匹配”，遇到第一个 就停。

• 所有量词都支持懒惰写法：*?、+?、??、{n,m}?
• 懒惰不等于“最短匹配”——它只保证局部最小，不保证全局最优；复杂嵌套仍可能出错（此时应改用否定字符类，如 [^）
• 性能上，懒惰量词可能回溯

  

  更多次，尤其在长文本中；若结构明确，优先用 [^x]* 替代 .*?

捕获组与非捕获组的实际取舍

写 (\d{4})-(\d{2})-(\d{2}) 很自然，但如果你只是想分组并复用（比如后面用 引用），而不需要提取每段年月日，那三个括号全是冗余捕获，拖慢性能还占内存。

这时候该用非捕获组：(?:\d{4})-(?:\d{2})-(?:\d{2})。它只分组、不保存匹配内容，正则引擎不会为它分配捕获编号。

• 命名捕获组（如 Python 的 (?P\d{4}) 或 JS 的 (?\d{4})）可读性高，但旧版环境（如 IE、某些嵌入式 JS 引擎）不支持
• 反向引用必须用捕获组，非捕获组不能被 \1 或 $1 引用
• 替换操作中若只用整个匹配（$& 或 &），而非子组，就完全没必要开捕获

不同语言/工具里的正则差异点

同一个正则，在 Python re、JavaScript、grep、sed 甚至 VS Code 查找框里，行为可能不同——不是语法错，是引擎实现或默认标志不一致。

比如行首锚定：^ 在多行模式下是否匹配每行开头？Python 默认不开启 re.MULTILINE，JS 需显式加 m 标志，而 grep -E 默认就是逐行处理，^ 天然生效。

• JS 不支持 \A 和 \Z（字符串绝对首尾），只认 ^/$ + m 标志
• Python 的 re.sub() 中，替换字符串里用 \1 引用捕获组；而 JS 用 $1，且 $& 表示整个匹配
• VS Code 查找框默认启用 g（全局）和 m（多行），但不支持 lookbehind（如 (?）除非开启实验性选项
• PostgreSQL 的 ~ 操作符使用 POSIX ERE，不支持 \d，得写 [0-9]

真正麻烦的不是学语法，而是每次粘贴正则前，先确认当前环境用的是什么引擎、开了哪些标志、哪些特性被禁用——漏看这一条，就足以让一个本该工作的正则彻底失效。