AuthenticationFailed错误大概率是authSource参数与用户创建数据库不一致所致，如用户在admin库创建则authSource必须为admin，不可省略或错配为其他库名。
authSource参数写错数据库名
连接时提示authentication failed或Command failed with error 13，但用户名密码没错——大概率是authSource指向了错误的数据库。MongoDB不会自动猜你把用户建在哪，必须显式告诉它。
- 如果用户是在
admin库创建的（绝大多数生产环境都这样），URI里必须写?authSource=admin - 写成
?authSource=vms_trace_point或干脆不写，MongoDB就会去目标库找认证信息，自然找不到 - Spring Boot里配
spring.data.mongodb.uri时同理，缺authSource参数等于没认证
PyMongo连接Atlas时authSource被忽略
mongodb+srv://协议下，PyMongo默认把authSource设为admin，但这个行为不可靠——尤其当Atlas集群启用了SCRAM-SHA-256且用户不在admin时，会静默失败。
- 显式加上
&authSource=admin（即使看起来冗余） - 更稳妥的做法：用
MongoClient构造时传authSource参数，例如MongoClient(uri, authSource='admin') - 别依赖驱动自动推断，特别是密码含特殊字符或使用自定义角色时
Go用mgo/v2连远程MongoDB报SASL失败
错误信息server returned error on SASL authentication step: Authentication failed不是驱动bug，而是URI解析机制限制：mgo.v2不从URI提取authSource，只认Database字段作为认证库。
- 弃用
mgo.Dial("mongodb://user:pass@host/db")这种写法 - 改用
mgo.DialWithInfo，明确设置Info.Database = "admin"（即认证源库） - 注意：这里的
Database不是你要操作的业务库，而是存用户凭证的库
用户确实存在但密码更新后仍认证失败
执行db.updateUser()后还是bad auth，常见原因是没在正确的认证库上下文里操作。
- 先
use admin再跑db.updateUser()，否则命令发到当前库，实际没生效 - 确认用户角色是否包含对目标库的操作权限，比如要读
vms_trace_point，角色得有{role:"read", db:"vms_trace_point"} - 重启应用或客户端连接池，旧连接可能还缓存着过期凭据
认证配置真正麻烦的不是语法，而是“哪个库存用户”和“哪个库要操作”这两件事必须分开想清楚。很多人卡在明明URI写了authSource却无效，其实是因为服务端用户根本不在那个库里——查show users前先use对应库，比反复改连接字符串管用。
