mongodb 不支持认证优先级或 sasl 加载顺序配置；priority 仅用于副本集选举，与认证无关；saslmechanisms 是只读声明，需显式列出并重启 mongod 才生效。
MongoDB 不支持“认证优先级”或“SASL机制加载顺序”的配置。它没有类似 LDAP 优先级、SCRAM-SHA-256 vs. SCRAM-SHA-1 的可调加载顺序，也没有 authenticationPriority 这类参数。
你遇到的可能是对术语的混淆：MongoDB 的 priority 字段只用于副本集选举（即 rs.conf() 中 members[n].priority），和认证完全无关。
为什么找不到 authenticationPriority 或 SASL 加载顺序配置？
- MongoDB 的 SASL 认证机制（如 SCRAM-SHA-1、SCRAM-SHA-256、PLAIN、GSSAPI）由客户端驱动协商决定，服务端仅声明支持哪些机制（通过
saslMechanisms配置项），不控制“加载顺序”。 - 服务端不会按优先级尝试多种机制；它只在握手时告知客户端自己支持的机制列表，客户端自行选择第一个匹配的（通常按自身默认策略，比如优先用 SHA-256）。
-
<code>saslMechanisms是只读声明，不是调度队列 —— 它不排序，也不影响“哪个先试”。
如何真正控制认证机制的可用性？
你只能通过以下方式显式启用/禁用特定机制，而非调整顺序：
- 在
<code>mongod.conf的<code>security段中设置：security: authorization: enabled saslMechanisms: SCRAM-SHA-256,SCRAM-SHA-1
- 如果只写
<code>SCRAM-SHA-256，则客户端必须支持该机制，否则连接失败。 -
<code>PLAIN（常用于 LDAP）需配合<code>ldap配置启用，且必须显式列出才可用。 - 修改后必须重启
<code>mongod（<code>systemctl restart mongod），热重载不支持<code>saslMechanisms。
常见错误现象：
- 客户端报错
<code>Authentication failed: Could not find a mechanism matching the requested one→ 服务端<code>saslMechanisms未包含客户端请求的机制。 - 使用旧版驱动（如 PyMongo
SCRAM-SHA-256的服务端 → 驱动不支持，会 fallback 失败。
副本集 priority 和认证完全无关，但容易被误改
-
<code>rs.conf()返回的配置里有<code>members[n].priority，这是选举权重，不是认证相关字段。 - 错误地执行
<code>cfg.members[0].priority = 0不会影响登录，但会让该节点永远无法成为<code>PRIMARY。 - 如果你在查
<code>rs.conf()时看到<code>priority: 1，别试图把它改成<code>authPriority: 2—— 这个键名根本不存在，<code>rs.reconfig()会直接拒绝。
真正需要关注的认证兼容性点
-
<code>SCRAM-SHA-256是 4.0+ 默认机制，但要求客户端驱动版本匹配（例如 Node.js<code>mongodb包 ≥ 3.6，Java Driver ≥ 3.11）。 - 启用
<code>SCRAM-SHA-1仅作兼容旧客户端用，不应在新部署中主动开启（SHA-1 已不安全）。 -
<code>GSSAPI（Kerberos）和<code>PLAIN（LDAP）需额外配置<code>ldap或<code>setParameter，且<code>saslMechanisms必须显式包含它们才能生效。 - 所有机制都依赖
<code>authorization: enabled，否则认证流程根本不会触发。
最常被忽略的一点：
修改 <code>saslMechanisms 后不重启 <code>mongod，配置完全不生效 —— rs.reconfig() 对它无效，mongosh 里的 db.runCommand({getCmdLineOpts: 1}) 也查不到运行时变更。
