MongoDB密码策略仅支持minLength和characterClassCount两项，需启用authorization才生效，且存在驱动截断、旧用户不强制刷新等问题，生产环境应由应用层校验密码。
MongoDB 本身不支持真正的密码复杂度策略，所有“内置策略”都严重受限或根本无效——你必须在应用层拦截并校验密码明文。
pwdPolicy 配置看似可用，实际只认两个字段
从 MongoDB 4.0 开始，setSecuritySettings 命令支持 pwdPolicy，但截至 v7.0（2026 年最新稳定版），只有 minLength 和 characterClassCount 真正起作用：
-
minLength: 10—— 强制最小长度，低于此值直接报错errmsg: "Password does not meet the minimum complexity requirements" -
characterClassCount: 3—— 要求至少含大写、小写、数字、特殊字符（!@#$%^&*()_+-=[]{}|;:,.?）中的任意三类；注意：中文、€、© 等符号不参与计数 -
maxRepetitions、notUserName、maxLength等字段在源码中仍是// TODO: implement状态，配了也白配 - 该策略仅对新创建用户或调用
db.changeUserPassword()的操作生效，旧用户密码不会被强制刷新
启用 pwdPolicy 前必须开启 authorization，否则完全静默失效
即使你正确执行了 db.adminCommand({ setSecuritySettings: { pwdPolicy: { minLength: 10, characterClassCount: 3 } } })，若未启用访问控制，整个策略会被 MongoDB 忽略，且不报任何日志或错误。
- 配置文件中必须明确设置：
security: { authorization: enabled } - 或启动时加参数：
mongod --auth --config /etc/mongod.conf - 改完配置必须重启
mongod，不支持热加载 - 验证是否生效：连接后执行
db.runCommand({ connectionStatus: 1 })，检查返回中是否有"authInfo" : { "authenticatedUsers" : [...] }；若为空，说明 auth 未真正启用
客户端驱动可能悄悄截断密码，导致策略校验失真
某些老版本驱动（如 mongodb@3.x Node.js 驱动、部分 Java 驱动）在解析连接字符串时，会把 pwd=abc&123! 中的 & 或 = 当作分隔符，只传一半密码给服务端。结果是：服务端校验的是截断后的弱密码，却误判为“符合策略”。
- 避免在连接串里传密码；改用
db.auth("user", "pwd")显式认证 - 验证密码是否被完整接收：创建用户后，运行
db.getUser("xxx")，检查credentials.scram["SCRAM-SHA-256"].saltedHash字段长度是否与预期哈希输出一致（通常 64 字符） - 若使用 URL 连接串，确保密码已 URL 编码（
encodeURIComponent("P@ss&w0rd!")）
真正可靠的方案：永远由服务层做明文校验
依赖 MongoDB 内置策略风险太高——字段残缺、行为不透明、驱动兼容性差。生产环境唯一可信赖的方式，是把密码校验收口到你的后端服务。
- 前端提交密码 → 后端用
zxcvbn或正则（如/^(?=.*[a-z])(?=.*[A-Z])(?=.*\d)(?=.*[!@#$%^&*()_+\-=\[\]{}|;:,.?]).{10,32}$/）校验 → 失败直接返回400 - 校验通过后，再调用
db.createUser()或db.changeUserPassword()，传入明文（MongoDB 内部自动哈希） - 若对接 LDAP/AD，密码策略必须在目录服务侧配置（如 AD 的
minPwdLength、OpenLDAP 的ppolicy模块），MongoDB 只做透传认证 - 特别注意角色权限匹配：即使密码很强，若用户没被赋予
dbAdmin却要执行collStats，照样报not authorized on admin to execute command，容易误判为认证失败
最易被忽略的点：策略只在校验明文阶段起作用，而明文只存在于你自己的服务内存里——一旦离开应用层，就再无干预机会。别指望 MongoDB 替你拦住 “Password123”。
