authsource 是强制声明的鉴权路径，指定用户凭证存储的数据库；它不决定权限范围，仅影响认证时查询凭据的位置，与 roles 中的 db 字段（权限作用域）无关。
authSource 不是“选填项”，而是鉴权路径的强制声明
MongoDB 的用户凭证不存于你要访问的目标库，而存于某个特定数据库——这个库就是 authSource。连接时驱动不会自动猜你用哪个库做认证，必须明确告诉它：去哪查用户名密码。比如连 testDB，但用户是在 admin 里创建的，那 authSource=admin 就不能省；否则会报 Authentication failed。
常见错误现象：
- 明明用户存在、密码正确，却始终提示
Failed to authenticate - 在
zy库创建了用户，连接字符串没带?authSource=zy，结果连不上 - 误以为
authSource是“权限作用域”，实际它只管“凭据在哪查”
authSource=admin 和 authSource=xxx 的本质区别
admin 是 MongoDB 的元数据管理库，所有跨库角色（如 root、clusterAdmin）都只能在这里定义；而普通业务库（如 orders、users）只应存放本库专用用户。两者的使用场景和安全边界完全不同：
- 用
authSource=admin：适合管理员、运维脚本、备份工具等需要多库操作的场景 - 用
authSource=orders：适合订单服务本身，只读写orders，凭据也锁死在该库，降低横向越权风险 - 8.0 版本行为变化：若用户建在
admin，部分旧驱动可能忽略authSource参数直接走admin；但若用户建在orders，authSource=orders就必须显式指定，否则找不到用户
连接字符串里漏掉 authSource 的典型报错与修复
最常遇到的是 MongoServerError: Authentication failed 或 error: Authentication failed. Username not found。这不是密码错了，而是驱动去错了库找用户。
实操建议：
- 先确认用户在哪建的：
use admin→db.getUser("myuser")；或use orders→db.getUser("myuser") - 按用户所在库补全连接串，例如用户在
orders：mongodb://myuser:pwd@localhost:27017/orders?authSource=orders - 不要依赖“默认行为”：4.x 默认 fallback 到
admin，8.0 更严格，不指定authSource就只查目标库（即/orders后面那个库），不会自动扫admin
为什么不能把所有用户都塞进 admin？
可以，但不推荐。这相当于把所有门禁卡都放在大楼总控室，一旦总控室被攻破，全部权限就丢了。更合理的方式是分层隔离：
-
admin只放极少数高权限账号（如 DBA、备份任务），且密码轮换频率更高 - 每个业务库自己建用户，用
authSource=该库名，即使某服务密钥泄露，影响也限于单库 - 注意
roles字段里的db值才是权限作用域，和authSource无关。比如{role:"readWrite", db:"logs"}表示能读写logs库，哪怕用户本人建在admin
真正容易被忽略的点是：authSource 决定“从哪读用户”，db 字段在 roles 里决定“能碰哪些库”——这两个值完全可以不同，但初学者常把它们混为一谈。
