SASL conversation error 根本原因是客户端与服务器在 SASL 协商阶段因机制不匹配、TLS 配置错误或证书问题导致连接中断，而非单纯认证失败。
为什么 sasl conversation error 总在连接时突然冒出来
这不是认证失败的常规报错，而是客户端和服务器在 SASL 协商阶段就断开了——比如服务端没开 SCRAM-SHA-256 支持，但客户端强行用它握手；或者 TLS 配置不匹配，导致加密通道建立失败，SASL 根本没机会跑完。
常见现象：MongoNetworkError: sasl conversation error: Authentication failed.（注意后半句是障眼法，真正卡在协商层）；Invalid SASL mechanism；Node.js 里抛 ERR_TLS_CERT_ALTNAME_INVALID 但错误堆栈里混着 SASL 字样。
- 确认 MongoDB 版本是否 ≥ 4.0：旧版默认只支持
SCRAM-SHA-1，新版默认启SCRAM-SHA-256，客户端若没显式指定机制，可能协商失败 - 检查连接字符串是否带
?authMechanism=SCRAM-SHA-256（或SCRAM-SHA-1），不能只靠驱动默认行为 - 如果用了 TLS/SSL，确保
tlsCAFile路径正确、证书未过期，且服务端配置了net.tls.mode: requireTLS或兼容模式
authMechanism 参数到底该填什么
不是所有驱动都自动降级。比如 Python 的 pymongo 4.0+ 默认用 SCRAM-SHA-256，但如果你连的是 3.6 集群，必须手动指定 authMechanism=SCRAM-SHA-1，否则直接报 SASL conversation error。
- 查服务端支持的机制：
db.runCommand({listMechanisms: 1})（需管理员权限） - Node.js 连接字符串示例：
mongodb://user:pass@host:27017/db?authMechanism=SCRAM-SHA-1 - Java Driver 要在
MongoClientSettings里显式 setAuthMechanism，不能只靠 URI - Go 的
mgo已弃用，用mongo-go-driver时，options.Client().SetAuth(options.Credential{AuthMechanism: "SCRAM-SHA-1"})
用了 TLS 就一定安全？未必，tlsInsecure 是把双刃剑
开发环境关校验证书很爽，但 tlsInsecure=true 会跳过整个 TLS 握手完整性检查，某些 MongoDB 版本（尤其是 4.4+）会在 SASL 阶段因缺少可信通道直接中止协商，反而触发这个错误。
- 生产环境禁用
tlsInsecure，改用tlsCAFile指向正确的 CA 证书文件路径 - 如果自签名证书，确保
tlsCertificateKeyFile和tlsCAFile都配全，且服务端net.tls.certificateKeyFile指向同一套证书 - Docker 场景下，宿主机证书文件挂载进容器后，
tlsCAFile路径要写容器内路径，比如/etc/ssl/mongo-ca.crt
云数据库（Atlas / ApsaraDB）的隐藏配置坑
Atlas 默认强制 SCRAM-SHA-256 + TLS 1.2+，但它的连接字符串里不显式写 authMechanism，很多用户复制完就跑，结果本地老版本驱动一连就崩。
- Atlas 连接字符串末尾加
&authMechanism=SCRAM-SHA-256（哪怕看起来冗余） - 阿里云 ApsaraDB for MongoDB 有些地域集群仍默认
SCRAM-SHA-1，得看控制台「数据库参数」页里的security.authorization和setParameter.saslMechanisms - 腾讯云 CVM 上自建 MongoDB，若启用了
bindIp: 127.0.0.1却用公网 IP 连，TLS 握手能过，SASL 协商却因 IP 不匹配被服务端静默拒绝
最麻烦的是错误信息不指向根因——它只说 SASL 失败，但真正拦路的可能是证书路径错、机制不匹配、甚至防火墙截断了部分 SASL 数据包。调的时候别只盯着 auth 字段，先抓包看前几个 TLS handshake record 有没有异常重传。
