必须停mongod进程才能绕过认证改密码，操作包括停服务、注释security.authorization、use admin后db.updateUser()修改密码、立即恢复配置并重启验证。
停服务后绕过认证连库改密码
必须停掉 mongod 进程，否则无法绕过认证。直接 kill 进程或用 systemctl stop mongod（Ubuntu/CentOS）或 net stop MongoDB（Windows）。别试“后台改配置再 reload”，MongoDB 不支持热更新 security.authorization 配置项。
停稳后，检查实际配置路径——常见的是 /etc/mongod.conf，但 Docker 容器里可能是 /etc/mongodb.conf 或根本没挂载配置文件；宝塔面板用户需进面板查“MongoDB 设置”页确认路径。找到后立刻备份：cp /etc/mongod.conf /etc/mongod.conf.bak。
编辑配置，注释或删掉这行：security.authorization: true。如果配置里用了缩进的 security: 块，整块清空更保险。YAML 对空格敏感，删完检查缩进是否一致，否则 mongod --config /etc/mongod.conf --dryRun 会报错。
连上去必须先 use admin
启动 mongod 后，直接执行 mongo（不带任何参数），它会连到默认 test 库。这时如果直接跑 db.updateUser("admin", {...})，实际改的是 test 库里叫 “admin” 的用户——而这个用户大概率根本不存在，白操作。
正确顺序只有三步：
- 输入
use admin（回车） - 再执行
db.updateUser("admin", {pwd: "new_strong_password", roles: ["root"]}) - 验证：
db.auth("admin", "new_strong_password")返回1才算成功
别用 db.changeUserPassword("admin", "...") ——它只改密码，不保留原有 roles，容易导致权限丢失。尤其当 admin 用户被赋予了多个 role（比如 clusterAdmin + userAdminAnyDatabase），changeUserPassword 会把它们全清掉。
改完立刻恢复认证并重启
很多人卡在最后一步：改完密码就以为结束了，忘了还原配置和重启服务。无认证状态多开一分钟，等于把数据库裸奔挂在公网。
还原配置时注意两点：
- 把之前注释掉的
security.authorization: true行加回去，确保缩进和原配置一致 - 运行
mongod --config /etc/mongod.conf --dryRun确认语法无误，再systemctl restart mongod
重启后立刻测试：mongo -u admin -p new_strong_password --authenticationDatabase admin。如果连不上，八成是配置没生效或服务没真正重启——查 systemctl status mongod 看进程 PID 是否变了。
Docker 和云数据库不适用这套流程
如果你用的是 Docker 官方镜像，且启动时用了 -e MONGO_INITDB_ROOT_USERNAME，那根本不用动配置文件：删容器、改环境变量、重跑 docker run 就行。硬去进容器改密码，反而可能因数据卷挂载导致配置冲突。
阿里云 DocDB、百度云 DocDB for MongoDB 这类托管服务，压根没给你文件系统权限。只能进控制台点“重置密码”，且仅限 root 账号——admin 用户得自己在启用认证后登录进去改，前提是还记得旧密码。
真遇到 TLS 或 LDAP 认证开启的状态，关 authorization 也没用。那种情况必须走对应认证后端的密码策略，比如联系 LDAP 管理员重置绑定账号。
