$regex直接写字符串不生效是因为默认区分大小写且无修饰符，需显式加$options:"i"实现模糊匹配；字符串写法更安全，但无前缀锚定时无法走索引，性能极差。
为什么 $regex 直接写字符串会不生效
常见现象是写成 { name: { $regex: "张" } } 却查不出 “张三”“张伟”，因为 MongoDB 的 $regex 默认是**区分大小写且不启用全局匹配**，更关键的是：它默认不带任何修饰符，等价于 /张/（只匹配子串），但实际执行时若没指定 $options，某些驱动或 shell 版本还会因隐式锚定行为导致意外失败。
真正要模糊匹配“包含张”，必须显式加 i（忽略大小写）和/或确保不被行首行尾锚定：
-
{ name: { $regex: "张", $options: "i" } }→ 匹配 “张”“张三”“小张” -
{ name: { $regex: "^张", $options: "i" } }→ 只匹配开头为“张”的（如“张三”，不匹配“小张”） - 避免写
{ name: { $regex: "张$" } }除非你真要找结尾是“张”的字段
用 JavaScript 风格正则字面量还是字符串？
MongoDB Shell（v4.4+）和大多数官方驱动（Node.js、Python PyMongo）都支持两种写法，但行为有差异：
- 字符串形式（推荐）：
{ name: { $regex: "张.*丰", $options: "i" } }—— 安全、可拼接、无转义陷阱 - 字面量形式（仅 shell 支持）：
{ name: { $regex: /张.*丰/i } }—— 在 Node.js 或 Python 中会报错，因为驱动把RegExp对象序列化为{}或直接拒绝 - 注意点：
.、*、^、$在字符串里要正常写，不用额外转义；但若字符串来自用户输入，必须先过滤或转义$、\，否则可能被注入恶意正则（比如.*导致全表扫描）
性能差得离谱？别让 $regex 扫全表
除非字段上有**前缀索引**，否则 $regex 基本等于全集合扫描。例如 { name: { $regex: "^张" } } 能走 name 字段的升序索引，但 { name: { $regex: "张" } }（无 ^）就完全无法利用索引。
- 能用
$in或$eq就别用$regex - 如果业务允许，把常用模糊前缀（如“张”“李”“王”）单独存成数组字段，用
$elemMatch查 - 对中文搜索，更靠谱的是用
text索引 +$text查询，或者接入 Elasticsearch - 测试时加
.explain("executionStats")看nReturned和totalDocsExamined是否接近——如果后者远大于前者，说明索引没生效
中文字符、emoji、空格匹配要注意什么
正则本身不区分中英文，但 MongoDB 的 collation 和存储编码会影响结果。例如：
- 中文全角空格
\s默认只匹配半角空格、换行、制表符，不匹配全角空格 - emoji 如
?属于 Unicode 扩展区，.能匹配，但某些旧版本驱动或 shell 可能因 UTF-8 解码问题截断 - 如果字段用了
collation: { locale: "zh" }创建，$regex仍按字节匹配，不会自动忽略拼音或笔画差异——别指望它替代中文分词 - 安全起见，对用户输入做最小化清洗：去掉首尾空格、统一空格类型、拒绝含
\x00-\x08\x0B\x0C\x0E-\x1F的非法控制字符
$regex 查询背后都可能拖慢整个集合，尤其是没索引支撑时。最常被忽略的不是语法，而是忘记检查 explain 输出里的 executionStats —— 那才是真实代价。 
