应先用 db.getuser() 显式检查用户是否存在，再决定是否创建，避免依赖 try/catch 捕获 createuser 错误；需在目标数据库上下文中执行（如 admin 库），注意 mongodb 6.0+ 跨库查询限制及 atlas 等托管服务禁用该命令的风险。
直接检查用户是否存在再创建，比捕获 createUser 报错更可靠、更干净——因为 MongoDB 不允许同名用户重复创建，但错误码不统一（比如 E13380、duplicate user 或网络层超时伪装成失败），且 db.createUser() 在用户已存在时不会返回标准的写入错误，而是抛出命令级异常，难以精准区分“真失败”和“已存在”。
用 db.getUser() 显式判断用户是否已存在
在初始化脚本里，不要依赖 try/catch 捕获创建失败来跳过；应先查后建，逻辑清晰、副作用可控。
-
db.getUser("admin")返回null表示用户不存在，返回对象表示已存在 - 必须在目标数据库上下文中执行：比如创建 admin 用户，得先切到
admin库：db = db.getSiblingDB("admin") - 注意：MongoDB 6.0+ 中
db.getUser()默认只查当前库用户；跨库查需指定{ filter: { user: "xxx", db: "admin" } }，但更简单的方式是显式切换库
避免 db.createUser() 被多次调用的典型陷阱
常见错误是把初始化逻辑放在容器启动脚本或 CI/CD 部署步骤中，未做幂等控制，导致每次重启都重试创建，最终报错中断流程。
- 脚本开头加
print("Initializing admin user...")和检查日志输出，便于定位是否被重复执行 - 不要在
mongosh连接后直接执行db.createUser()——如果连接的是副本集主节点，而脚本被多个实例并发运行，仍可能因竞态导致报错（虽然概率低） - 若用 Kubernetes Job 执行初始化，确保
restartPolicy: Never且 Job 名带唯一哈希，防止重名 Job 多次触发
为什么不用 db.updateUser() 替代？
db.updateUser() 要求用户必须已存在，否则报错 UserNotFound；它不适合“有则更新、无则新建”的场景，也不能替代初始化判断逻辑。
- 它不能设置新角色，只能修改已有字段（如密码、
customData） - 没有类似 SQL 的
INSERT ... ON CONFLICT DO UPDATE语义 - 想批量管理用户？得自己封装逻辑：先
getUser，再分叉调用createUser或updateUser
真正容易被忽略的是：MongoDB Atlas 等托管服务禁用 createUser 命令，此时脚本会直接失败——初始化前务必确认部署环境是否支持该命令，否则得改用云控制台或 API 创建用户。
