应使用$regexfind而非$regex进行字段内容提取，因其返回结构化匹配结果且支持聚合管道中任意阶段；$regex仅限$match阶段过滤，无法提取子串。
聚合里用 $regexFind 而不是 $regex 做字段内匹配
在聚合管道中直接用 $regex 无法对字段内容做提取或条件判断，它只支持查询级过滤（即只能用在 $match 阶段），且不返回匹配结果本身。真正要在清洗流程中“从文本里抠出邮箱”“提取手机号”这类操作，必须用 $regexFind——它是 MongoDB 5.0+ 才支持的聚合表达式，返回结构化匹配对象（含 match、idx、captures 等字段）。
常见错误是把查询语句原样搬进聚合：比如写 {"$match": {"bio": {"$regex": /@.+\..+/}}}，这只能筛出含邮箱的文档，但无法把邮箱单独拎出来存成新字段。而 $regexFind 可以嵌入 $addFields 或 $set 中：
{ "$set": { "extracted_email": { "$regexFind": { "input": "$bio", "regex": /([a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,})/ } } } }
注意：$regexFind 不会报错于空值或 null 输入，而是安静返回 null，所以后续要用 $ifNull 或 $cond 处理。
大文本字段正则性能差？先切片再匹配
MongoDB 对长文本（如 content 字段超 1MB）执行正则时，即使加了索引也无效——全文索引不覆盖 $regex，而普通索引只对前缀有效（如 /^ERROR:/）。真实场景中，日志、评论、爬取正文等字段往往含大量无关字符，硬扫全字段既慢又易 OOM。
解决思路不是优化正则，而是缩小输入范围：
- 用
$substrCP截取前 500 字符（按 Unicode 码点，避免截断中文）再传给$regexFind - 若业务允许，提前在写入时用应用层预处理，将关键信息（如 URL、错误码）单独提成字段并建索引
- 对超长字段，考虑用
$text+ 全文索引替代模糊正则，尤其当目标是关键词存在性判断而非精确模式提取
示例：只检查评论开头是否含敏感词
{ "$set": { "has_badword": { "$ne": [{ "$regexFind": { "input": { "$substrCP": ["$comment", 0, 500] }, "regex": /违禁|诈骗/i } }, null] } } }
$match 阶段别滥用正则，尤其不能放管道后半段
很多同学想“先投影再筛”，比如先 $project 出一个拼接字段 full_text: { "$concat": ["$title", " ", "$content"] }，再用 $match: { "full_text": { "$regex": /xxx/ } }。这会导致两个严重问题：
- 所有文档都得加载进内存做拼接，哪怕 99% 本该被过滤掉
-
$match在非首阶段无法走索引，变成全量扫描
正确做法是：把能用索引的硬条件前置，例如
- 时间范围：
{"created_at": {"$gte": ISODate("2026-01-01")}} - 状态标记：
{"status": "published"} - 已知前缀的 ID：
{"log_id": {"$regex": /^ERR-/}}（这个能走索引）
这些 $match 必须放在管道最开头，之后再用 $regexFind 做精细清洗。
清洗后字段为空？检查捕获组和 null 处理逻辑
$regexFind 默认只返回第一个匹配，且如果正则没写捕获组（()），captures 字段永远是空数组，match 才是完整匹配字符串。但如果你依赖 captures.0 却忘了加括号，就会得到 undefined。
更隐蔽的问题是：当输入字段为 null、"" 或缺失时，$regexFind 返回 null，而后续直接 "$extracted_email.match" 会触发路径错误（Cannot read property 'match' of null）。
安全写法是显式兜底：
{ "$set": { "email": { "$ifNull": [ { "$getField": { "field": "match", "input": { "$regexFind": { "input": "$bio", "regex": /([^\s@]+@[^\s@]+\.[^\s@]+)/ } } } }, ""] } } }
实际生产中，建议把这类清洗逻辑封装成可复用的 $let 表达式，避免每处都重复写 null 判断。
真正容易被忽略的是：$regexFind 的 PCRE 引擎对 Unicode 支持虽好，但某些边界情况（如带 emoji 的邮箱、ZWNJ 分隔的域名）仍可能漏匹配，上线前务必用真实脏数据样本验证。
