MongoDB用户已授权却执行失败，主因是authSource与用户所在库不匹配或roles中db字段与操作库名不一致；需确保连接串含正确authSource，且角色db值严格等于目标库名。
用户已授权却执行命令失败，大概率不是权限没给，而是 authSource 和角色绑定库不匹配，或者操作库与角色声明的 db 字段对不上。
authSource 参数错配导致认证成功但授权失效
客户端连接串里 authSource 指向的库，必须和创建用户时所在的库一致。比如用户是在 admin 库建的，但连接串漏了 ?authSource=admin，MongoDB 就会默认去目标库（如 vms_trace_point）查用户——查不到，就跳过授权校验直接报 Unauthorized。
-
mongosh "mongodb://user:pass@localhost:27017/vms_trace_point"→ 默认在vms_trace_point查用户，失败 -
mongosh "mongodb://user:pass@localhost:27017/vms_trace_point?authSource=admin"→ 显式指定，才能命中admin库里的用户定义 - Spring Boot 的
spring.data.mongodb.uri同样必须带authSource，否则等效于第一种情况
roles 里的 db 字段和实际操作库名不一致
用户角色中 db 值必须和你要操作的库名完全一致。哪怕只差一个大小写或下划线，权限也不生效。
- 执行
db.getUser("myuser")，看roles数组里每个对象的db字段值 - 如果角色是
{role:"readWrite", db:"admin"}，但你在vms_trace_point库执行insert，就会报not authorized on vms_trace_point to execute command - 补授权用
db.grantRolesToUser("myuser", [{role:"readWrite", db:"vms_trace_point"}])，注意db值要严格匹配
权限集不足以覆盖当前操作
角色只给了 read，却执行 insert 或 createIndex；或者只给了 readWrite，却调用了 dropDatabase —— 这些都会失败，且错误码仍是 13 (Unauthorized)，容易误判为没授权。
-
readWrite不含dropCollection、createCollection等元数据操作权限 -
dbAdmin才能执行dropDatabase、compact等库级管理命令 - 用
db.runCommand({connectionStatus: 1})查当前会话有效权限，比猜更可靠
最容易被忽略的是：authSource 错配时，日志里几乎不报错，只在客户端看到模糊的 Unauthorized；而 roles.db 不匹配时，db.getUser() 返回结果一眼就能看出问题，但很多人根本不去查。
