MongoDB 5.0 并未废弃旧版安全选项，而是提升安全基线：security.authorization 虽非强制启动失败，但不启用将导致 RBAC 失效且客户端认证失败；net.ssl.mode: preferSSL 已弃用，仅 requireSSL/allowSSL 有效；SCRAM-SHA-1 彻底移除，必须升级为 SCRAM-SHA-256；bind_ip 默认行为影响扩大，需显式配置 IPv6 或启用 net.bindIpAll 并强化网络防护。
MongoDB 5.0 并没有“废弃”旧版安全选项，而是将部分配置项从可选变为强制启用，或调整了默认行为——这本质上是安全基线的上移，不是功能删除。
为什么 security.authorization 现在必须显式开启
在 4.4 及更早版本中，security.authorization: false 是合法且常见的配置，尤其在开发环境。5.0 开始，虽然该配置项仍被识别，但若未设为 true，启动时会输出明确警告（非错误），并强烈建议启用；更重要的是，某些新特性（如细粒度角色权限、system.roles 的动态刷新）仅在授权启用后才完整生效。不设它，等于主动放弃大部分 RBAC 能力。
- 如果你还在用
mongod --noauth启动，5.0 会拒绝连接来自启用了SCRAM-SHA-256认证机制的客户端（这是 5.0 默认驱动行为） -
mongosh连接时若服务端未启用 auth，会提示Warning: Authentication failed，即使你没输密码——因为客户端默认尝试协商认证 - 配置文件中遗漏
security.authorization: true不会导致启动失败，但会让后续创建用户、分配角色等操作全部无效
net.ssl.mode 从 preferSSL 降级为弃用
5.0 中 net.ssl.mode: preferSSL 仍被接受，但官方文档已标记为 deprecated。真正生效的只有 requireSSL 和 allowSSL（后者仅限测试）。原因很直接：允许明文通信的模式与现代最小攻击面原则冲突，且 preferSSL 在实践中容易因客户端配置疏漏导致降级到非加密连接。
- 使用
preferSSL时，如果客户端未提供证书或未启用 TLS，连接仍会建立，但全程无加密——这在审计中属于高风险项 - 5.0+ 驱动（如 Node.js 的
mongodb@4.13+）默认要求服务端 TLS 配置为requireSSL，否则抛出MongoServerSelectionError - 若你依赖旧版客户端（如 Python 3.6 + PyMongo 3.12），它们可能不支持
requireSSL的握手流程，需同步升级客户端库
SCRAM-SHA-1 被禁用，SCRAM-SHA-256 成为唯一默认机制
5.0 彻底移除了对 SCRAM-SHA-1 的支持。这不是配置开关问题，而是二进制层面的裁剪：启动时若检测到用户凭据仍用 SHA-1 加密存储（即 system.users 中 mechanism: "SCRAM-SHA-1"），服务会拒绝加载该用户，并报错 Authentication failed: UserNotFound。
- 升级前必须运行
db.updateUser()重置所有用户密码，触发重新哈希为 SHA-256 格式 - 不能靠“先连上再改”，因为旧密码无法通过 SHA-1 认证登录——必须用 4.4 或更早版本导出用户凭证，再在 5.0 中重建
- 如果你用 LDAP 或 x.509，此限制不适用，但需确认目录服务本身支持 SHA-256 协商
最易忽略的一点：bind_ip 默认值未变，但影响已不同
5.0 仍默认 bind_ip: 127.0.0.1，但新增了 net.bindIpAll 参数。很多人误以为设 bind_ip: 0.0.0.0 就够了，其实不然：
-
bind_ip: 0.0.0.0会监听所有 IPv4 接口，但若系统启用了 IPv6，mongod仍不会监听::1（IPv6 loopback），导致部分本地工具（如某些监控 agent）连接失败 - 正确做法是显式写
bind_ip: 127.0.0.1,::1，或启用net.bindIpAll: true（注意：该参数在 5.0 中默认为false，且开启后必须配合防火墙策略） - 若你用容器部署，
bind_ipAll可能绕过 Docker 的网络隔离，让服务意外暴露在宿主机网桥上
