最可靠方式是用pymongo.mongoclient显式指定authsource、设置serverselectiontimeoutms超时，并区分connectionfailure与operationfailure异常；必须对admin、test、local等常见认证库逐个尝试，空口令需传空字符串，仅当operationfailure含“authentication failed”才判定为弱口令。
直接用 pymongo.MongoClient 连接并试登录是最可靠的方式，但必须显式指定 authSource、控制超时、并准确区分异常类型，否则会漏掉空口令、认证库错配或误判连接失败为弱口令风险。
authSource 参数不显式指定就等于白扫
MongoDB 的认证数据库（authSource）和用户所在数据库是两个概念。脚本里只传 username 和 password，默认用 admin 做 authSource——但生产环境里，用户很可能建在 test、myapp 甚至自定义库中。结果就是报错 not authorized on admin to execute command，你以为是密码错，其实是连认证入口都找错了。
- 必须对常见认证库逐个尝试：
authSource="admin"、authSource="test"、authSource="local" - 如果目标环境有明确的业务库名（如
finance），也应加入尝试列表 - 空口令用户（如
pwd=""）必须显式传空字符串，不能传None或省略password字段
ConnectionFailure 和 OperationFailure 必须分开处理
网络不通、bindIp 配置错误、服务未响应，都会触发 ConnectionFailure；而 OperationFailure 才代表“连上了但认证失败”。把两者混为一谈，会把真实弱口令藏在一堆超时误报里。
- 设置
serverSelectionTimeoutMS=3000控制连接建立阶段超时，避免卡死 - 仅当
OperationFailure异常消息中含"Authentication failed"或"auth failed"，才算一次有效认证失败 -
ConfigurationError（比如authSource库不存在）需单独捕获，不计入弱口令判断
生产环境扫描必须限速且避开敏感操作
高频试探会触发防火墙限速、填满 mongod 日志、甚至导致连接池耗尽。真正的风险不是“能不能扫到”，而是“扫的时候别让系统抖一下”。
- 单 IP 对单实例建议 ≤ 5 并发线程，每次尝试间隔 ≥ 1.5 秒
- 禁用
ssl=True除非确认服务端启用了 TLS，否则直接连接失败 - 优先测试高危组合：
user in ["admin", "root", "mongoadmin"]+pwd in ["", "admin", "123456", "password", "root"] - 一旦成功执行
db.adminCommand("listDatabases")，说明已通过认证，可立即终止该用户的字典尝试
最难的不是写几行 try/except，而是从一堆 OperationFailure 中识别出那个真正能连上却没报错的空口令——它往往出现在第一个连接成功的 case 里，而不是等你跑完全部字典才出现。
