\b 在中文里会静默失效：三个正则坑和一份能用的字符边界方案

`\b` 在中文里会静默失效：三个正则坑和一份能用的字符边界方案

用户发来一张截图：他勾了「全字匹配」，把文档里的一个词换成另一个词，导出，打开------一个字都没变。

没有报错，没有提示，进度条正常跑完，文件正常下载。

我第一反应是他的输入有问题。第二反应是文件编码。第三反应才轮到那行正则------而问题就在那行正则里。

这篇文章写三个坑。三个都不抛异常，三个都只在「搜索词是中文」的时候发作。

测试环境：Node 22 / Chrome 最新版。下面每段输出都是真跑出来的。

坑一：`\b` 对纯中文搜索词永远不成立

\b 的定义是「\w 与 非\w 的交界」，而 JS 里的 \w 只有 [A-Za-z0-9_]。中文不在里面。

于是同一行代码，两种结果，取决于搜索词长什么样：

js 复制代码

/\bhello\b/g.test('你好hello世界')   // true
/\b你好\b/g.test('你好世界')          // false
/\b猫\b/g.test('一只猫两只猫')         // false

第一行为什么是 true？因为「好」是非 \w，「h」是 \w，交界成立。第二行为什么是 false？「你」和「好」都不是 \w，两端都没有交界------一个位置都不成立，所以永远不会匹配。

第一行是个陷阱。 你拿英文测通了，就以为 \b 能用；上线之后中文用户一个都替换不到。而且它连警告都没有，test() 返回 false 而已，你的代码很可能压根没检查。

我当时那段代码是这么写的：

js 复制代码

if (wholeWords) regex = new RegExp(`\\b${escaped}\\b`, flags)

escaped 是把用户的输入转义后的结果。英文词正常，中文词全程空转。用户看到的是「功能坏了」，我看到的是「正则没问题」。

坑二：lookbehind 是正解，但 Safari 会直接抛错

知道 \b 不行之后，正解很自然：断言「前面不是字母数字」。

js 复制代码

/(?<![\p{L}\p{N}_])猫(?![\p{L}\p{N}_])/gu

\p{L} 是「任意语言的字母」，汉字算在里面；u 标志不能少，否则 \p{...} 只是个普通字符类，行为完全不同。

Chrome、Firefox 正常。这条也不是我测出来的------是一个 Safari 用户的控制台截图：

vbnet 复制代码

SyntaxError: Invalid regular expression: invalid group specifier name

Safari 16.4 之前的正则引擎不支持 lookbehind。new RegExp(...) 在这一行就抛，不会走到 test()。

关键在「直接抛」这三个字。如果你的正则在渲染期就构造好了（useMemo 里 new、模块顶层 new），抛错的后果不是「全字匹配失效」，是整个组件白屏------一个可选的勾选框，把整个页面干掉了。

Safari 16.4 是 2023 年 3 月发布的。2026 年手上还有一堆没升级的 iPad 和旧 iPhone，这个坑现在依然是活的。

替代方案：把前导字符吞掉再回填

不能用 lookbehind，就用「捕获 + 回填」模拟同样的语义：

js 复制代码

// 捕获组 1 = 前导分隔符（或行首）；尾随的 (?!...) 只断言，不消费字符
const re = /(^|[^\p{L}\p{N}_])(?:猫)(?![\p{L}\p{N}_])/gu

'猫和猫粮，猫咪说：猫。'.replace(re, (_m, p1) => p1 + '【狗】')
// → '猫和猫粮，猫咪说：【狗】。'

两个细节：

(?:...) 是非捕获组。别用捕获组包搜索词 ，否则用户自己写的 $1 会错位。
捕获组 1 必须回填，否则每替换一次就吃掉前面那个标点。

它比 lookbehind 多一个不明显的好处：相邻两次匹配各自需要自己的前导字符，不存在「两个匹配抢同一个分隔符」的冲突。lookbehind 是零宽断言，理论上可以共享边界；吞字符的写法做不到共享，但也因此不会出现「第二个匹配莫名其妙没了」的情况。

代价是每次替换都得拼回去。忘了拼，输出里就会少一个逗号------这种 bug 比不替换更难发现。

坑三：`replace` 回调的第 2 个参数，是偏移量不是分组

这个坑最隐蔽，因为它在「有捕获组」时表现完全正常。

js 复制代码

'x'.replace(/x/, (...args) => args.map(v => typeof v))
// ['string', 'number', 'string']
//   ↑ 匹配到的文本  ↑ 偏移量      ↑ 原串

无捕获组时，第 2 个参数是 number。所以这段代码：

js 复制代码

text.replace(/(?:猫)/g, (_m, p1) => p1 + '狗')

p1 是数字，输出会变成 0狗1狗2狗------每个匹配位置都被当成前缀拼进去了。

正确做法是按模式分三支，别用一个 replacer 打天下：

js 复制代码

if (useRegex) {
  // 正则模式：保留用户写的 $1 / $&，交给 String.replace 原生处理
  return input.replace(regex, replace)
}
if (wholeWords) {
  // 全字模式：第 1 组是被吞掉的分隔符，必须回填
  return input.replace(regex, (_m, p1) => p1 + replace)
}
// 纯文本模式：零参 replacer，既回填字面量，又防止 $& 被解释
return input.replace(regex, () => replace)

第三支也重要。纯文本模式下用户输入 $& 应该原样出现在结果里；如果用 replace(re, replace)，$& 会被当成「插入整个匹配」的占位符，用户输入什么就变什么。零参箭头函数是唯一干净的做法。

中文其实没有「词边界」

前面那套 (?![\p{L}\p{N}_]) 看着能用了，但它不是「词边界」，是「字符边界」。差别在一次实测里就露出来了：

js 复制代码

'猫和猫粮，猫咪说：猫。'.match(re).length   // 1

四个「猫」，只命中一个------句末那个。

因为「和」「粮」「咪」都算字母类字符，断言把它们全排除了。这其实符合「全字匹配」的语义：猫粮里的猫不该被替换。但它同时也意味着**「猫和」里的第二个字也不算边界**，因为中文不用空格分词，正则无从判断哪里是词。

想更准，只能上分词：

js 复制代码

[...new Intl.Segmenter('zh', { granularity: 'word' }).segment('猫和猫粮，猫咪说：猫。')]
// 猫 | 和 | 猫 | 粮 | ，| 猫咪 | 说 | ：| 猫 | 。

注意它的判断：把「猫粮」拆成两个词，却把「猫咪」当成一个词。词典决定结果，不同引擎的词典还不一样。

也就是说，分词反而让结果更不可预测。如果你的替换要跨浏览器一致，字符边界的近似比分词更可靠。

最后的选择

三种写法摊开对比：

写法	中文可用	Safari 兼容	相邻匹配	实现成本
`\b词\b`	❌ 纯中文永不匹配	✅	---	一行
`(?<!...)(?!...)`	✅	❌ 16.4 前抛错	可共享边界	一行，但会白屏
`(^	[^\p{L}\p{N}_])(?:词)(?!...)`	✅	✅	各自独立

我最后选了第三种，并且在 UI 上改了一句话：把「全字匹配」的说明从「按词匹配」改成「要求前后不是字母或数字」。

这不是文字游戏。对中文，「词」这个概念在正则层面不存在，承诺「按词匹配」就是在承诺一件做不到的事。把限制说清楚，用户遇到边界情况时不会以为是 bug，而是知道这就是规则。

四行正则，三个坑，全都不会报错。这类问题最难的地方从来不是修，是发现。

\b 在中文里会静默失效：三个正则坑和一份能用的字符边界方案