JavaScript正则难点在于边界场景：默认.不匹配换行，^/$只锚定首尾；需用/s/m标志或[\s\S]替代；match、exec、test适用场景不同；否定匹配应避免过度回溯，优先前置过滤；新特性需考虑环境兼容性。
JavaScript 正则表达式本身不难，难的是写对——尤其是当你要匹配嵌套结构、排除特定上下文、或处理换行/空白敏感场景时，RegExp 很快就会暴露它的边界。
为什么 /^abc.*?def$/ 在多行文本里总不生效？
因为默认的 . 不匹配换行符（\n、\r），且 ^ 和 $ 只锚定字符串首尾，不是每行起止。
- 加
s标志让.匹配换行：/^abc.*?def$/s - 加
m标志让^/$匹配每行开头结尾：/^abc.*?def$/gm - 两者可共存：
/^abc.*?def$/gms，但注意：V8（Chrome / Node.js ≥15.8）才完全支持s；旧环境得用[\s\S]替代.
match()、exec() 和 test() 该选哪个？
三者行为差异直接影响你能否拿到全部捕获组、是否要循环遍历、以及性能表现。
-
str.match(/a(b)c/g)→ 返回所有完整匹配的数组（无捕获组）；加g才全量，否则只返回第一个+捕获信息 -
regex.exec(str)→ 每次调用返回一个结果（含index、groups），需手动循环；带g时会推进lastIndex，适合流式解析 -
regex.test(str)→ 只返回true/false，但有陷阱：如果正则带g，多次调用会在内部维护lastIndex，导致偶发false（尤其在复用正则对象时）
怎么安全地匹配「不包含某子串」的文本？
别用 (?!...) 直接包住整个目标——那是常见误用。否定逻辑必须结合「原子性」和「回溯控制」才能稳定。
立即学习“Java免费学习笔记（深入）”；
- 错误写法：
/^(?!.*unwanted).*target.*$/—— 看似排除unwanted，但.*会过度回溯，长文本下极易超时 - 推荐写法：
/^(?:(?!unwanted).)*target.*$/，其中(?:(?!unwanted).)*是“原子性否定序列”，逐字符检查不触发unwanted - 更稳妥的替代：先用
!str.includes('unwanted')做前置过滤，再进正则匹配，逻辑清晰且无回溯风险
捕获组命名、后行断言这些新特性能随便用吗？
可以，但得看运行环境。Node.js 12+ 和 Chrome 73+ 支持命名捕获组（(?），但 Safari 直到 16.4 才完全支持后行断言（(?）。
- 命名捕获组示例：
/(?→ 结果中\d{4})-(? \d{2})-(? \d{2})/.exec('2023-04-01') groups.year直接可用 - 后行断言慎用：
/(? 匹配美元符号后的数字，但 IE 完全不支持，旧版 Edge 也不行 - 兼容性兜底方案：用普通捕获组 + 数组索引，或借助
String.prototype.replace()的回调参数间接提取
真正复杂的匹配（比如解析 Markdown 表格、提取嵌套 JSON 片段、识别带引号的 CSV 字段）往往超出正则能力边界。这时候与其硬刚回溯深度和边缘 case，不如分层处理：先用简单正则切块，再用状态机或专用 parser 处理语义。
