脚本连不上而mongosh能登录的根本原因是authSource未对齐：MongoDB要求显式指定用户所在认证库（如admin或test），不能依赖默认值；若不匹配则报“not authorized on admin to execute command”。
直接用脚本连 MongoDB 试登录是最可行的方式，但必须显式指定 authSource、正确区分异常类型、并控制并发节奏，否则不是漏掉空口令，就是被误判为“连不上”。
为什么脚本连不上，而 mongosh 能登录？
根本原因在于认证数据库（authSource）没对上。MongoDB 不像 MySQL 那样默认在连接库认证，而是要求明确指定用户创建所在的数据库——比如用户建在 test 库，脚本却默认用 authSource="admin" 去认证，就会报 not authorized on admin to execute command。
- 必须显式传参：
authSource="test"或authSource="admin"，不能依赖默认值 - 若不确定用户在哪建的，需对常见库（
admin、test、local）逐个尝试 - 空密码不能传
None或省略，得写成pwd="" -
ConnectionFailure（连不上）和OperationFailure（连上了但认证失败）必须分开处理，前者不反映密码强弱
如何用 Python 脚本批量检测弱密码用户？
核心是构造最小可行探测逻辑：只试高危组合（如 user in ["admin", "root", "mongodb"] + pwd in ["", "123456", "admin", "password", "mongodb"]），并限制单 IP 并发 ≤ 5、间隔 ≥ 1.5 秒，避免触发防火墙限速或填满日志。
- 连接时设
serverSelectionTimeoutMS=3000，防止卡死 - 捕获
OperationFailure后检查e.errmsg是否含"Authentication failed"，才是有效失败 - 一旦成功建立连接且能执行
db.adminCommand({"listDatabases"})，立刻终止该用户的后续测试——说明已拿下 - 别用完整字典扫，优先验证已知风险点；真正难的是从一堆
OperationFailure中识别那个“连得上但没报错”的空口令，它往往出现在第一次连接成功时
检测到弱密码后，怎么强制用户改密？
MongoDB 没有“强制过期”机制，所谓“强制更换”只能靠策略+操作双驱动：先启用密码复杂度策略（pwdPolicy），再调用 db.changeUserPassword() 主动重置。
- 策略生效前提：必须开启
security.authorization: enabled，否则setSecuritySettings完全被忽略 - 真正起作用的只有两个字段：
minLength: 10和characterClassCount: 3（大小写字母+数字+特殊字符中至少三类） -
maxRepetitions、notUserName等字段目前仍是 // TODO 状态，配了也白配 - 旧用户不受策略自动约束，必须手动执行
db.changeUserPassword("xxx", "NewPass@2026")才触发校验 - 客户端驱动可能静默截断含
&或=的密码（尤其老版 Node.js 驱动），建议用db.auth()显式认证，而非依赖连接串传密
最难的不是写出检测脚本，而是判断哪些用户值得优先扫、哪些密码组合最可能命中、以及如何从看似正常的连接响应里揪出那个没报错的空口令——它通常藏在第一个 ConnectionSuccess + no auth error 的 case 里，而不是等你跑完字典才出现。
