错误13（Unauthorized）根源是用户认证数据库（authSource）与目标库不一致，或角色未授予对应数据库权限；需检查authSource配置、用户所在库及roles字段中的db值是否匹配目标库。
确认当前连接用户在哪个数据库下创建
错误 Command failed with error 13 (Unauthorized) 的根源，往往不是密码错，而是「用户归属的认证数据库」和「你正在操作的目标数据库」不一致。MongoDB 的用户是绑定在某个数据库（authSource）下的，不是全局账户。
比如你在 admin 库创建了用户 myuser，但 Spring Boot 配置里连的是 vms_trace_point 库，且没显式指定 authSource=admin，MongoDB 就会默认去 vms_trace_point 里找 myuser —— 找不到，就报错 13。
- 用
mongosh登录时必须带上--authenticationDatabase参数，例如：mongosh "mongodb://localhost:27017/vms_trace_point" --authenticationDatabase admin - 如果登录失败，先换到
admin库验证用户是否存在：use admin; db.getUser("myuser") - 若返回
null，说明该用户根本不在admin下，得查你实际创建它的库（比如vms_trace_point）
检查用户是否拥有目标库的 read / readWrite 角色
即使用户存在，角色（role）不对也会触发 error 13。MongoDB 不认“超级管理员”概念，read 和 readWrite 必须明确授予具体数据库。
执行以下命令确认权限：
use admin
db.getUser("myuser")
看返回里的 roles 字段是否包含类似这样的条目：
{ "role" : "read", "db" : "vms_trace_point" }
如果没有，或 db 值是 admin 而不是你操作的库名，就需补授权：
- 确保已用管理员账号登录（如
db.auth("root", "pwd")） - 切换到
admin库：use admin - 执行：
db.grantRolesToUser("myuser", [{role:"readWrite", db:"vms_trace_point"}])
Spring Boot 中 authSource 配置漏写或写错
spring.data.mongodb.uri 里 authSource 参数不是可选的 —— 它是强制项，尤其当用户不在目标库下创建时。
常见错误写法：
-
mongodb://user:pass@localhost:27017/vms_trace_point→ 缺authSource，MongoDB 默认查vms_trace_point库，大概率失败 -
mongodb://user:pass@localhost:27017/vms_trace_point?authSource=vms_trace_point→ 如果用户其实在admin下，这等于告诉 MongoDB “去vms_trace_point找认证信息”，还是找不到
正确写法（假设用户在 admin 下）：
mongodb://user:pass@localhost:27017/vms_trace_point?authSource=admin
注意：authSource 的值必须和你创建用户时所在的数据库完全一致，大小写敏感，不能拼错。
Debezium 或 MongoTemplate 执行命令类操作时额外需要 clusterAdmin 权限
普通 find 或 insert 只要 readWrite 就够；但像 runCommand、aggregate（尤其带 $changeStream）、listCollections 这类元数据或集群级操作，可能要求更高权限。
例如 Debezium 启动时的 aggregate 报错 not authorized on admin to execute command { aggregate: 1, ... }，说明它试图在 admin 库做变更流聚合，但当前用户没被授予 admin 库的 clusterMonitor 或 readAnyDatabase 角色。
- 临时验证：用管理员账号执行
db.runCommand({connectionStatus: 1})，看是否成功 - 生产环境不建议直接给
root权限，应按最小权限原则追加：db.grantRolesToUser("myuser", [{role:"clusterMonitor", db:"admin"}]) -
MongoTemplate.getDb().runCommand(...)类调用，务必确认命令语义是否跨库或涉及集群状态
最容易被忽略的一点：MongoDB 用户权限不是“设置完就生效”的——修改角色后，已建立的连接不会自动刷新权限，必须重启应用或等待连接池重建。别在改完权限后立刻测试却看到同样报错，先 kill 掉旧连接。
