AuthenticationFailed错误主因是authSource未指定或与用户创建库不一致；MongoDB用户归属具体数据库，必须显式设置authSource匹配其所在库（如admin），且大小写敏感，连接串末尾的数据库名仅指定默认操作库，与认证无关。
认证失败不是密码输错了，大概率是连接字符串或认证上下文没对齐。MongoDB 的 auth 机制比表面看起来更严格，尤其在启用了权限控制的部署中。
authSource 参数漏设或设错
MongoDB 不会默认去 admin 库找用户，除非你明确告诉它——否则它只在连接串末尾指定的数据库（比如 mydb）里查用户。如果你的用户是在 admin 创建的（绝大多数生产环境都是），却没传 authSource，就会报 Authentication failed。
正确做法是显式指定：
mongoose.connect('mongodb://localhost:27017/mydb', {
auth: { username: 'admin', password: 'p@ss:w0rd' },
authSource: 'admin'
});
- 不要依赖连接串里拼
@后面的库名来决定认证源 -
authSource和实际创建用户的数据库必须完全一致（大小写敏感） - Atlas 部署强制要求
authSource=admin，漏掉必挂
用户名或密码含特殊字符未转义
连接串里出现 @、/、:、% 等字符时，URL 解析器会提前截断。比如用户名是 dev@prod，不转义就等价于 mongodb://dev@prod:xxx@host/db，解析器会把第一个 @ 当作协议分隔符，后面全乱。
最稳的方式是避开手动拼接和转义：
- 用
auth选项对象传凭证，驱动内部处理原生字符串 - 避免写
mongodb://dev%40prod:pass%2Fword@localhost:27017/db这类易出错的串 - 环境变量注入时也走
auth对象，别拼进 URL 字符串
连接地址用 localhost 导致 IPv6 认证绕过
Node.js 16+ 默认优先走 IPv6，localhost 解析成 ::1，但 MongoDB 服务可能只监听 127.0.0.1（IPv4）。这时连接看似成功，实则没走认证流程，后续操作直接报 not authorized。
验证方式：
- 用
mongosh "mongodb://127.0.0.1:27017/test?authSource=admin"手动连，看是否还失败 - 检查
mongod启动日志，确认 bindIp 是否包含::1 - 开发时统一用
127.0.0.1替代localhost，省去排查成本
用户权限范围与操作目标不匹配
MongoDB 用户只能在「自己所属的数据库」里登录，管理员也不例外。比如你在 admin 创建了用户 backup，但它没有 readWrite 权限给 logs 库，那用这个用户连 mongodb://127.0.0.1:27017/logs 就会失败——即使 authSource=admin 正确。
关键点：
- 先确认用户在哪建的：
use admin; db.getUser("backup") - 再查它被授了哪些库的权限：
db.getUser("backup").roles - 连哪个库，就要确保该用户对该库有对应角色（
read、readWrite、dbAdmin等）
最容易被忽略的是：用户权限是「库粒度」的，不是「实例粒度」的。连错目标库，认证通过了也会在执行操作时报 not authorized。
