$regexMatch不生效主因是版本低于4.2或误用于find()；它仅限聚合管道，需配合$expr在$match中使用，或在$addFields中生成布尔值，且不走索引。
为什么 $regexMatch 在聚合管道里不生效？
因为 $regexMatch 是 MongoDB 4.2+ 引入的聚合操作符，不是 shell 命令或 find() 的查询语法；直接写成 { name: { $regex: "abc" } } 在 $match 阶段能用，但无法做“匹配结果布尔判断”——比如你想标记某字段是否命中正则，再基于这个布尔值分组或过滤，就必须用 $regexMatch。
常见错误现象：unknown operator: $regexMatch，通常是 MongoDB 版本低于 4.2；或者误把它当查询操作符写在 find({}) 里，而不是聚合管道的 $match 或 $addFields 中。
- 必须运行在 MongoDB 4.2 及以上版本
- 只能用于聚合管道（
aggregate()），不能用于find() - 返回布尔值，不是匹配内容本身
$regexMatch 的基本写法和参数含义
$regexMatch 接收一个对象，必须包含 input、regex 两个键，options 是可选字符串（如 "i" 忽略大小写、"m" 多行模式）。
示例：判断 email 字段是否为合法格式（简化版）：
[
{
$addFields: {
is_valid_email: {
$regexMatch: {
input: "$email",
regex: "^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$",
options: "i"
}
}
}
}
]
-
input必须是字符串类型字段，若为 null 或非字符串，结果为false（不会报错） -
regex可以是字符串字面量，也可以是变量（如"$pattern"），但不能是正则字面量/.../ -
options不支持"g"（全局匹配无意义，它只判断是否匹配一次）
在 $match 阶段用 $regexMatch 过滤 vs 直接用 $regex
两者都能实现“按正则筛选”，但语义和性能有差异：
- 直接写
{ $match: { name: { $regex: "foo", $options: "i" } } }更简洁，兼容性更好（所有版本都支持） - 用
{ $match: { $expr: { $regexMatch: { input: "$name", regex: "foo", options: "i" } } } }才能配合其他表达式，比如：$and里混用字段比较和正则、或基于计算字段做匹配 - 索引使用上：原生
$regex在某些前缀场景（如^abc）可能走索引；而$regexMatch在$expr内部一律不使用索引，全表扫描风险更高
所以除非你需要布尔中间结果，否则优先用原生 $regex。
容易被忽略的转义和 Unicode 问题
正则字符串里的反斜杠要双重转义：MongoDB 解析一层，正则引擎再解析一层。比如想匹配 d+，实际得写 "\\d+"（4个反斜杠）。
更隐蔽的是 Unicode 字符处理：
-
$regexMatch默认按 UTF-8 字节匹配，不自动识别 Unicode 字符边界 - 若正则含中文、emoji 等，确保
regex字符串本身编码正确（Node.js 驱动通常没问题，Shell 里粘贴需注意） - 不支持
uXXXX转义写法，必须用实际字符或\uXXXX（即字面量 Unicode 转义需四层反斜杠）
例如匹配中文“测试”：推荐直接写 "测试"，而非 "\u6d4b\u8bd5"，后者易出错且可读性差。
