90%的AuthenticationFailed错误源于authSource配置错误，它必须等于用户创建所在的数据库名（如admin或myapp），而非目标业务库；未指定时默认为admin，易导致认证失败。
authSource参数没配对是最常见原因
90%的OperationFailure: authentication failed错误，不是密码错了，而是authSource值和用户实际创建所在的数据库不一致。MongoDB不查“全局用户表”，每个用户都绑定在一个具体数据库里——你在哪个库执行db.createUser()，那个库就是它的authSource。
常见错觉：把authSource设成你要操作的业务库（比如myapp），但用户其实在admin里建的，结果PyMongo去myapp库里找用户，自然找不到。
- 用户在
admin库创建 → 连接时必须显式传authSource="admin" - 用户在
myapp库创建 →authSource="myapp"，哪怕你连的是otherdb - 连接字符串里没写
authSource→ PyMongo默认用admin，本地单节点常因此失败 -
mongodb+srv://协议下，?authSource=xxx会被忽略，必须用关键字参数传：MongoClient(uri, authSource="admin")
SCRAM-SHA-256认证机制不兼容
MongoDB 4.0+ 默认启用SCRAM-SHA-256，但旧版PyMongo（如3.x）只支持SCRAM-SHA-1。现象是：客户端能成功建立TCP连接，MongoClient初始化不报错，但第一次调list_collection_names()或find()才抛出AuthenticationFailed。
验证方式：进mongosh执行db.runCommand({connectionStatus: 1}).authInfo.authenticationMechanisms，看返回是否含"SCRAM-SHA-256"。
立即学习“Python免费学习笔记（深入）”；
- 确认服务端机制后，升级PyMongo到4.0+（推荐4.7+）可自动协商
- 若无法升级，临时降级服务端机制（不推荐生产环境）：
mongod --setParameter authenticationMechanisms=SCRAM-SHA-1 - 极少数场景需手动指定机制：
mechanism='SCRAM-SHA-1'传给MongoClient（注意：4.7+已弃用该参数）
Atlas、副本集、分片集群的authSource固定为admin
MongoDB Atlas强制所有用户建在admin库，所以authSource必须是"admin"，无论你连哪个数据库。副本集或分片集群也一样——认证必须走admin，即使用户角色只针对某个业务库。
容易踩坑的是：你在Atlas控制台看到“Database User”页面，以为用户名和库名是绑定的，其实它只是角色范围，认证源永远是admin。
- Atlas连接字符串示例：
mongodb+srv://user:pass@cluster.mongodb.net/mydb?retryWrites=true→ 必须补authSource="admin"参数 - 副本集配置中，即使
replicaSet=myrs，也不影响authSource取值逻辑 - 用
mongosh --apiVersion 1 --username user --password pass --authenticationDatabase admin能连上，就说明服务端没问题，问题一定出在PyMongo配置
低代码平台或老旧驱动不支持authSource怎么办
某些Dataphin、Airbyte等平台的MongoDB连接器不暴露authSource配置项，会强制用你填的“数据库名”作为认证源。这时复用admin用户必然失败。
解决办法不是改平台，而是换账号策略：
- 登录
mongosh，先use your_target_db，再执行db.createUser({user:"dp_user", pwd:"xxx", roles:["readWrite"]}) - 平台配置里，“数据库名”填
your_target_db，“用户名”填dp_user - 避免跨库授权（如
{role:"readWrite", db:"otherdb"}），这类角色在无authSource支持的平台下不可用
真正麻烦的从来不是密码输错，而是你以为的“数据库名”和MongoDB认定的“用户归属地”根本不是一回事——查清用户在哪建的，比反复试密码快十倍。
