嘿，我特别理解你现在的困惑——明明单独的ñ能正常匹配到文本里的内容，可一加上\b单词边界（不管是加在前面还是后面）就匹配失败了，反而ASCII的n怎么组合\b都没问题，这反差感确实让人摸不着头脑对吧？

咱们先拆解下原因：Go的regexp包底层用的是RE2正则引擎，而RE2对\b（单词边界）的判断是严格基于ASCII字符集的。具体来说，\b只匹配以下两种位置：

1. 字符串的开头/结尾，且紧邻的字符是ASCII的字母、数字或下划线（也就是\w在ASCII下覆盖的范围：[A-Za-z0-9_]）；
2. 一边是ASCII的\w字符，另一边是非ASCII的\w字符（或者字符串开头/结尾）的位置。

那回到你的测试用例：

• 测试3（ñ）能匹配，这个很好理解，文本里确实存在这个字符；
• 测试2（ñ\b）：你期望的是匹配ñ后面跟着一个单词边界，但ñ属于Unicode字母，不在ASCII的\w范围内。它后面的空格是“非ASCII的\w”字符，这时候ñ和空格之间的位置，两边都不属于ASCII的\w，完全不符合RE2对\b的定义，所以整个正则表达式就匹配不到任何内容了；
• 测试0、1的\bñ\b和\bñ同理：ñ本身不是ASCII的\w，所以它前后的位置都不满足\b的匹配条件，自然就匹配失败了。

而ASCII的n属于\w范围，它和空格之间的位置就符合\b的要求，所以不管是\bn\b还是n\b都能正常匹配。

这并不是Go的regexp包有bug，而是RE2引擎的设计初衷——为了极致的性能，它只支持ASCII范围内的\w、\b等元字符，不支持Unicode扩展的单词边界判断（这属于WAI，也就是“按设计工作”）。

如果你需要对Unicode字符做单词边界匹配，得手动用Unicode属性来定义边界，比如把匹配单独ñ的正则改成：

(?<![\p{L}\p{N}_])ñ(?![\p{L}\p{N}_])

这里\p{L}匹配任意Unicode字母，\p{N}匹配任意Unicode数字，这个正则就能准确匹配到文本中作为单独“单词”存在的ñ了。

内容来源于stack exchange