JavaScript中/\w+/会漏匹配含下划线的标识符，因其边界受非\w字符（如-）中断；应改用/a-zA-Z_*/g，并注意转义、贪婪性及exec()的lastIndex复用问题。

JavaScript 中用 RegExp 或字面量写正则，不是“记住了就能用”，关键在「边界控制」和「转义一致性」——尤其遇到下划线 _ 这种既不是单词字符也不是空白的符号时，稍不注意就漏匹配或过度匹配。

为什么 /\w+/ 会漏掉带下划线的字符串？

\w 在 JavaScript 中等价于 [a-zA-Z0-9_]，看起来包含下划线，但问题常出在「上下文边界」：比如你想匹配变量名 user_name，但写成 /\w+/g 在字符串 "let user_name = 123" 中确实能捕获，可一旦它出现在连字符后如 "data-user_name"，\w+ 就只拿到 "user"（因为 - 不是 \w，匹配在 - 处中断）。

• 真正要匹配「含下划线的标识符」，得显式定义字符集：/[a-zA-Z_][a-zA-Z0-9_]*/g
• 开头不能是数字，所以首字符单独限定为 [a-zA-Z_]，后续才允许 0-9
• 别依赖 \w 做标识符匹配——它的行为在 Unicode 模式下还会变（u 标志启用时支持更多语言字母）

String.prototype.match() 和 RegExp.prototype.exec() 匹配结果差异

两者对全局标志 g 的处理逻辑不同，直接影响你能否拿到所有含下划线的子串：

• "a_b c_d".match(/[a-z_]+/g) → ["a_b", "c_d"]（返回全部匹配数组）
• const r = /[a-z_]+/g; r.exec("a_b c_d") → 第一次只返回 ["a_b"]，需循环调用才能取完
• 如果忘了重置 lastIndex（比如正则对象复用），exec() 可能直接返回 null，而 match() 没这问题

匹配含下划线的路径或文件名时，别忽略转义和贪婪陷阱

比如想从 "src/utils/helper_v2.js" 中提取 "helper_v2"，写成 /[a-z_]+(?=\.js)/i 看似合理，但实际可能跨过中间路径：

const str = "src/v2_helper/main.js";
str.match(/[a-z_]+(?=\.js)/i); // → ["v2_helper/main"] —— 错！因为 [a-z_]+ 是贪婪的，一直吃到点号前

• 更安全的是锚定位置：/[a-z_]+(?=\.js$)/i（加 $ 确保点号在末尾）
• 或者用非贪婪：/[a-z_]+?(?=\.js)/i，但需确认前面没有其他点号干扰
• 路径场景建议优先用 split('/').pop().replace(/\.js$/, '')，比正则更稳

下划线本身在正则里不用转义（它不是元字符），但写在字符组里要注意位置：放在开头或结尾最安全，比如 [_a-z]；若写成 [a-z_-]，- 会被当成范围连接符，导致语法错误或意外含义。