中文匹配失败主因是Sublime未正确加载UTF-8编码，尤其Windows下无BOM的UTF-8文件易被误判为GBK，导致\u4e00-\u9fa5等正则失效；须确认状态栏显示UTF-8，必要时Reopen或Save with BOM。
中文匹配失败，是不是正则写错了？
不是正则写错，而是 Sublime 没正确加载 UTF-8 编码——尤其 Windows 下打开无 BOM 的 UTF-8 文件时，常被误判为 GBK，导致 [\u4e00-\u9fa5] 全部失效，连“一”都匹配不到。此时无论你怎么调正则，结果都是零匹配。
必须先确认右下角状态栏显示的是 UTF-8（不是 Western (Windows 1252) 或 GBK）。若不对：
- 执行 File → Reopen with Encoding → UTF-8（强制重载）
- 或更稳妥： File → Save with Encoding → UTF-8 with BOM，Sublime 对带 BOM 的 UTF-8 支持最稳定
- 避免用
[一-龥]这类模糊范围，它依赖字体和编码实现，易漏字；优先用[\u4e00-\u9fa5]或[\u4e00-\u9fff]
为什么 \w 匹配不到中文、emoji 或下划线变量名？
\w 在 Sublime 的 Boost 正则引擎中只等价于 [a-zA-Z0-9_]，完全不认 Unicode 字符。所以 \b\w{4}\b 在中文文本里永远返回 0 结果，user_name 中的 _ 会被当作单词边界切开。
真正能跨语言匹配「连续非空白字符」的写法是：
- 纯中文/日文/韩文词：
[\u4e00-\u9fa5\u3040-\u309f\u30a0-\u30ff]{3}（3 字词） - 含中英文数字的通用组合：
[^\s]{4}（但必须配合Whole Word或负向断言，否则会从“人工智能”里截出“人工智”） - 想严格限定单词边界（避开
user_name中的name）：(?，注意 <code>\b对中文无效，必须用(? 和 <code>(?!\w)
$1 引用中文捕获组时乱码或输出空？
这不是引用语法问题，而是捕获本身失败了——根源仍在编码。如果文件没以 UTF-8 加载，哪怕你写了 ([\u4e00-\u9fa5]+)，括号内也根本没捕获到任何内容，$1 自然为空或乱码。
验证步骤必须做：
- 先关闭替换，只在
Ctrl+F查找面板中输入你的中文正则，确认高亮是否出现 - 确保查找框右下角
.*图标已点亮，且状态栏编码为UTF-8 - 捕获组内不要混用未转义的特殊字符，比如
姓名：(.*)中的中文冒号不用转义，但点号.要写成\.才匹配字面量 - 替换时统一用
$1，别用\1或${1}——后者在部分版本中虽能工作，但不稳定
跨行匹配中文内容总卡死或吞太多？
根本原因是 .*? 在开启 . matches newline 后，面对大段中文+换行极易触发回溯爆炸，Sublime 直接假死。别硬扛。
更稳的写法是放弃 .，改用显式字符集：
- 匹配任意内容（含中文、换行）：
[\s\S]*?，不是.*? - 匹配带中文的 HTML 标签体：
<div>]*>([\s\S]*?)</div> - 提取函数体（含中文注释）：
function\s+\w+\s*\(\)\s*\{([\s\S]*?)\} - 大文件（>5MB）慎用跨行正则；先用
Ctrl+Shift+F定位到含中文的目标文件，再分块操作
真正容易被跳过的动作，是每次输完正则后，不点 Find All 看高亮数量就直接点 Replace All——这一步省掉，后面全是白忙活。
