正则匹配是状态驱动的NFA推演过程，含贪婪匹配与回溯；^强制开头匹配，\b是\w与\W边界；re.match()仅起始尝试，re.search()逐位置调用；JS的/test()/g有lastIndex状态风险；\b在中文中失效，需改用(?
正则表达式匹配不是“扫描”，而是“状态驱动”的尝试过程
正则表达式引擎不会像普通字符串查找那样线性扫一遍就完事。它先把你的模式（比如 /a+b?c/）编译成一个状态机（通常是 NFA），然后拿着输入字符串，从左到右“推演”每一步可能的路径。这个过程天然带试探性——比如遇到 + 或 *，引擎会先尽可能多吃字符（贪婪），发现后面匹配不上时，再“吐回”一些重试（回溯）。
- 没加
^和$时，引擎默认从字符串每个位置都尝试启动匹配，直到成功或耗尽位置 - 锚定符
^不是“跳过前面”，而是强制要求匹配必须从字符串开头开始；\b这类零宽断言不消耗字符，只校验位置 - 量词嵌套（如
(x+)+）极易引发“灾难性回溯”——输入稍长就卡死，这是线上服务中真实发生的超时根源
Python 的 re.match() 和 re.search() 差别远不止“开头 vs 全局”
re.match() 只在字符串起始位置尝试一次；re.search() 才是真正从头到尾逐个位置调用匹配逻辑。但很多人忽略的是：它们底层共用同一套 NFA 引擎，只是起始调用点不同。这意味着即使你用 re.search()，如果模式本身含 ^，它依然只会在字符串开头匹配——^ 锁死的是“匹配发生的位置”，不是函数行为。
-
re.match(r'abc', 'xabc')→None（开头不满足） -
re.search(r'^abc', 'xabc')→None（^强制开头，而字符串以 x 开头） -
re.search(r'abc', 'xabc')→ 匹配成功（找到子串） - 性能上，
re.match()在确定只需检查开头时更快，但无实质编译差异；频繁使用应预编译：pattern = re.compile(r'\d{3}-\d{2}-\d{4}')
JavaScript 的 .test() 方法背后有隐式状态，多次调用可能出错
当正则表达式对象带 g（全局）标志时，.test() 会维护内部的 lastIndex 属性，记录上次匹配结束位置。下次调用不是从头开始，而是从 lastIndex 继续——这在循环或并发调用中极易导致漏匹配或无限循环。
const r = /a/g;
console.log(r.test('ab')); // true
console.log(r.test('ab')); // false ← lastIndex 已移到1，下次从索引1开始，'b'不匹配
console.log(r.lastIndex); // 1
- 修复方法：每次调用前手动重置
r.lastIndex = 0，或干脆去掉g标志（.test()多数场景不需要全局） - 更安全的替代：用
String.prototype.match()或正则字面量直接调用（/a/.test('ab')每次都是新实例，无状态） - 注意：Firefox 曾有 bug 导致
lastIndex在某些失败匹配后未重置，跨浏览器务必测试
写正则时最常被忽视的“字符边界”其实是语义边界
很多人知道 \b 是单词边界，但误以为它只分隔字母数字和空格。实际上，\b 是“\w 和 \W 相邻的位置”，而 \w 包含下划线 _。所以 cat_\b 能匹配 cat_，但 cat.\b 却不能匹配 cat.（因为 . 是 \W，cat 结尾是 \w，相邻成立）——可一旦后面跟数字或下划线，边界就消失了。
-
邮箱验证中写
\b[A-Za-z0-9._%+-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}\b是错的：末尾\b会被 TLD 后的标点（如句号、括号）破坏 - 真正需要的是上下文控制，比如用
(?（负向先行断言）代替开头\b，更精确 - 中文场景下
\b完全失效（中文字符不属于\w），此时必须用(? 这类 Unicode-aware 断言（需u标志）
