$function 性能极差，应优先用原生阶段或聚合表达式替代；若必须使用，须严格限制输入规模、确保纯函数且前置 $match 过滤。
$function 是 JavaScript 引擎执行的，不是原生 C++ 实现
MongoDB 的聚合管道中，绝大多数阶段（如 $match、$group、$sort）由 WiredTiger 存储引擎和内核 C++ 代码直接处理，能高效利用索引、内存预分配和向量化操作。而 $function 会将每个文档传入 JS 引擎（V8 或 SpiderMonkey），在隔离沙箱中逐个调用用户函数 —— 这意味着：
- 无法下推到存储层，必须先加载完整文档（哪怕只用其中 1 个字段）
- 每文档一次 JS 函数调用开销：上下文切换 + 序列化/反序列化 BSON ↔ JS 对象
- 完全绕过所有索引优化，
$function内部的条件判断不会触发索引扫描 - 不支持并行化处理，只能单线程串行执行（即使数据分片也难横向加速）
替代方案优先级：从原生操作到聚合表达式再到 $function
只要能用原生阶段或聚合表达式实现，就绝不该用 $function。常见场景对比：
- 字符串截取、日期计算、数值四则运算 → 用
$substr、$dateTrunc、$add等原生表达式，零 JS 开销 - 复杂条件分支（如多层嵌套 if-else）→ 拆解为
$cond+$switch+$let，仍走 C++ 解析器 - 需要正则提取或 JSON 解析 → 先确认
$regexFind、$jsonSchema是否满足；仅当逻辑涉及外部状态或动态代码生成时，才考虑$function - 已有 JS 工具函数想复用 → 评估是否可提前在应用层处理，或改写为聚合表达式
启用 $function 时必须加硬性约束
若业务强依赖 $function（如合规性脱敏、特定哈希逻辑），务必限制其作用范围，否则极易拖垮整个管道：
- 必须前置
$match，确保输入文档数 ≤ 数百量级；千万级集合上用$function等同于全表 JS 循环 - 禁止在
$function中调用db.collection.find()等数据库操作（会报错）或eval()（被禁用） - 函数体必须是纯函数：无副作用、无外部依赖、不修改参数对象（MongoDB 会冻结传入文档）
- 测试时用
explain("executionStats")对比：开启前后executionTimeMillis和totalDocsExamined是否跳变式增长
真正慢的不是 $function 本身，而是它暴露的设计缺陷
生产环境里，一个聚合中出现 $function 往往意味着更深层问题：
- 数据模型没归一化：本该存成独立字段的计算结果，却每次运行时现场算
- 业务逻辑侵入数据库层：应由应用服务处理的规则（如权限校验、格式转换）被塞进聚合
- 缺乏预计算机制：高频使用的派生字段未通过
$addFields+ 定时 job 预写入
与其花时间调优 $function 的 JS 代码，不如回溯一步：这个逻辑真的必须在数据库里跑吗？
