正则匹配是状态驱动的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 继续——这在循环或并发调用中极易导致漏匹配或无限循环。
