最稳妥的方式是直接用 db.changeUserPassword() 修改密码，它不删用户、不重置角色、不中断连接，是官方推荐的在线修改方式；需用 userAdminAnyDatabase 或 root 角色改他人密码，userAdmin 可改自己密码；pwd 字段已废弃，手动更新 system.users 会导致认证失败。
直接用 db.changeUserPassword() 修改密码最稳妥
只要用户已存在、且你当前已用具备权限的账号（比如 admin）成功认证，就能直接调用这个命令改密。它不删用户、不重置角色、不中断连接，是 MongoDB 官方推荐的在线修改方式。
常见错误现象：执行后提示 not authorized on admin to execute command { changeUserPassword: ... } —— 说明当前登录账号没权限操作该用户。必须用 userAdminAnyDatabase 或 root 角色的账号登录才能改别人密码；改自己密码则至少要有 userAdmin 角色。
- 先连上：
mongosh "mongodb://admin:oldpass@localhost:27017/admin" - 切换数据库：
use admin - 执行修改：
db.changeUserPassword("target_user", "new_secure_password")
注意：密码明文传入，别在命令行历史里留痕。生产环境建议用 passwordPrompt() 替代硬编码，例如：db.changeUserPassword("target_user", passwordPrompt())，终端会交互式隐藏输入。
为什么不能直接 db.updateUser() 改 pwd 字段？
MongoDB 6.0+ 的 SCRAM-SHA-256 认证机制下，pwd 字段已废弃。手动更新 system.users 集合里的 pwd 不生效，反而可能破坏用户文档结构，导致后续 auth 失败或角色丢失。
真正存储的是 credentials 字段下的哈希值，由服务端在创建/修改时自动生成。绕过 changeUserPassword() 或 updateUser() 的标准流程，等于跳过认证校验逻辑，大概率让账号“变砖”。
使用场景仅限于极特殊调试——比如你明确知道目标用户用的是旧版 SCRAM-SHA-1 且未升级，但这种情况在 6.0 默认配置中几乎不存在。正常运维请彻底放弃手改集合这条路。
改完密码后连接失败？检查这三处
改密本身很快，但连接失败往往卡在下游环节，不是命令问题：
-
mongosh连接字符串里还带着旧密码 —— 检查脚本、环境变量、连接池配置，尤其是MONGODB_URI这类全局变量 - 应用代码里硬编码了密码，没走配置中心或密钥管理 —— 这属于安全反模式，趁这次一并重构掉
- 客户端驱动版本太老（比如 pymongo Authentication failed，需升级驱动或显式降级认证机制（不推荐）
验证是否生效，最简方式是新开一个 mongosh 窗口，用新密码直连：mongosh "mongodb://target_user:new_secure_password@localhost:27017/mydb"。
轮换密码时最容易被忽略的点
改密不是单点操作。真实环境中，密码常被多处引用：应用配置、CI/CD 流水线、监控告警脚本、备份任务、甚至某些临时调试工具。漏掉一处，就可能触发告警风暴或备份失败。
更隐蔽的风险是连接池复用：有些框架（如 Node.js 的 mongodb driver）默认启用连接池，旧连接可能还在用老凭证通信，直到连接超时或主动断开。所以改密后观察 5–10 分钟，确认所有依赖服务都平稳过渡，比单纯执行一条命令重要得多。
