disableJavaScript 不存在于 MongoDB 官方配置中；真正禁用需设 enableJavaScript: false（4.2–5.0）或省略该参数（6.0+默认禁用），并配合权限控制与应用层拦截。
为什么 disableJavaScript 不能直接关掉 eval 和 $where
因为 MongoDB 的 JavaScript 禁用机制是分层的：服务端脚本（如 eval 命令、$where 查询、mapReduce）依赖 javascriptEnabled 全局开关，但这个开关在 4.4+ 版本已被移除，且 disableJavaScript 并非配置项——它根本不存在于任何官方配置文件中。很多人搜到过这个伪参数，其实是把旧版文档或第三方文章里的错误写法当真了。
- MongoDB 从 4.2 开始默认禁用
eval命令；4.4 起彻底移除eval命令支持 -
$where仍被保留，但必须显式启用javascriptEnabled: true（仅限mongod启动时通过--javascriptEnabled或配置文件设置），而该选项在 6.0+ 已标记为 deprecated，未来会强制关闭 -
mapReduce在 5.0+ 默认禁用，需手动开启enableJavaScript: true配置项（注意：不是disableJavaScript）
如何真正禁用服务器端 JS：从启动参数到权限控制
核心思路是「不让它加载，也不让谁调用」。光改配置不够，得配合角色权限和运行时限制。
- 启动
mongod时明确禁用 JS 引擎：--javascriptEnabled false（4.2–5.0 支持），6.0+ 必须省略该参数（默认 false），否则启动失败 - 配置文件中对应写法：
setParameter: { enableJavaScript: false }（注意键名是enableJavaScript，不是disableJavaScript） - 删除或限制内置角色：
dbAdmin和root角色可执行$where；应创建最小权限角色，不授予find操作的javascript行为（MongoDB 本身不按行为授权，所以靠禁止使用含 JS 的操作符） - 应用层拦截：在驱动或 API 网关里正则匹配请求体中的
$where、$function、mapReduce字段，直接拒绝
$function 和 $accumulator 是新风险点，比 $where 更隐蔽
5.0 引入的聚合阶段 $function 允许内联 JS 函数，它绕过了传统 $where 的语法限制，且默认启用——只要 enableJavaScript: true 就能跑。很多团队升级后没意识到这点，以为关了 $where 就安全了。
-
$function必须配合allowDiskUse: false和严格超时（maxTimeMS）使用，否则可能被用来做 DoS - 它不校验函数签名，传入恶意字符串如
"while(true){}"会导致 CPU 占满 - 替代方案优先用原生聚合操作符：
$switch、$cond、$let；实在要逻辑计算，用应用层处理，别塞进数据库 - 监控日志关键词：
command: { aggregate: ..., $function: ... }，发现就告警
验证是否生效：别只看配置文件，要实测
配置写了不等于起效。常见假阳性是：配置 reload 失败、容器未挂载新配置、副本集成员配置不一致。
立即学习“Java免费学习笔记（深入）”；
- 连接后执行：
db.runCommand({ getCmdLineOpts: 1 })，检查返回中parsed.setParameter.enableJavaScript是否为false - 尝试触发 JS 功能：
db.collection.find({ $where: "true" })应返回error: "JavaScript is disabled"（不是语法错） - 对
$function测试：db.collection.aggregate([{$function: { body: function() { return 1; }, args: [], lang: "js" }}])，预期报错errmsg: "JavaScript execution is disabled" - 注意：某些云托管服务（如 Atlas）根本不开放
enableJavaScript配置，JS 功能永久关闭——此时测试失败反而是正常现象
最常被忽略的是副本集主节点和从节点配置不同步，或者用了 mongos 但只改了 config server 的配置。JS 控制粒度是进程级的，每个 mongod 实例都得单独确认。
