MongoDB 6.0升级后首次连接报AuthenticationFailed，主因是authSource未显式指定为admin、SCRAM-SHA-256机制未启用、featureCompatibilityVersion未设为"6.0"及SSL/TLS配置不匹配。
authSource 参数必须显式指定为 admin
升级后首次连接就报 authentication failed，但用户名密码确认无误——大概率是 authSource 没配对。MongoDB 6.0 默认不再隐式推断认证数据库，尤其当用户在 admin 库中创建时，连接串里必须带 ?authSource=admin。Navicat 界面里的 “Database” 输入框填的是默认打开库，不是认证源，二者不能混用。
- 错误示例：
mongodb://user:pass@localhost:27017/myapp（没指定authSource，6.0 会尝试在myapp库里找用户） - 正确写法：
mongodb://user:pass@localhost:27017/myapp?authSource=admin - 若用户建在其他库（如
auth），则authSource=auth，不能硬写admin
SCRAM-SHA-256 成为唯一支持的认证机制
MongoDB 6.0 彻底移除了 SCRAM-SHA-1，所有用户必须使用 SCRAM-SHA-256。如果你是从 4.4 升级上来，且用户是旧机制创建的，db.updateUser() 不会自动升级哈希算法，必须手动重建或迁移。
- 检查现有用户机制：
db.getUser("username", { showCredentials: true })，看credentials.SHA-256字段是否存在 - 旧用户无法直接登录：即使密码正确，也会返回
AuthenticationFailed错误 - 重建方案：
db.createUser({ user: "u", pwd: "p", roles: [...], mechanisms: ["SCRAM-SHA-256"] }) - 注意：驱动也需支持 SHA-256，Node.js 驱动 v4.13+、Python PyMongo v4.0+ 才默认启用
featureCompatibilityVersion 必须设为 "6.0"
升级 mongod 后，如果没运行 setFeatureCompatibilityVersion 命令，部分安全特性（包括认证流程）仍按旧版本逻辑执行，导致看似连接成功、实际鉴权绕过或失败。
- 确认当前 fCV：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }) - 升级后必须手动设置：
db.adminCommand({ setFeatureCompatibilityVersion: "6.0" }) - 该命令需在
admin库下执行，且所有节点（副本集/分片）都要运行 - 未设置时，
serverStatus输出中metrics.authentication可能缺失关键字段
SSL/TLS 要求变严格，影响凭证传输路径
6.0 对 TLS 握手阶段的证书校验更严，尤其在启用 net.tls.mode: requireTLS 时，若客户端未提供有效 CA 或跳过验证，认证凭据可能根本无法送达服务端，表现为超时或 connection closed，而非明确的 auth 错误。
- 本地测试可临时关 SSL，但生产环境必须配全：CA 文件、证书链、私钥，且
tlsAllowConnectionsWithoutCertificates: false（默认） - 云服务（如 Atlas）强制要求
authSource=$external+ TLS，填admin会静默失败 - Java 驱动需显式加
&ssl=true&sslInvalidHostNameAllowed=true（仅测试），生产必须校验证书
真实场景里，这四点常叠加出现：fCV 没升 → 认证机制未切换 → authSource 又没写对 → 最后 TLS 握手卡住。调试时别只盯错误信息字面，得一层层查配置落地状态。
