mongodb 6.0 不支持 fle 2.0 集合级自动加密，因其协议与元数据格式未被 mongod 识别，驱动会报错“auto encryption is not supported for this server version”。
MongoDB 6.0 副本集本身不支持集合级别的自动加密（FLE 2.0），autoEncryption 功能在 6.0 中仅处于公共预览阶段，且已被明确弃用——它与 7.0 GA 版本的 Queryable Encryption 不兼容，也无法在生产环境中启用集合级字段加密规则。
为什么 MongoDB 6.0 无法真正使用 FLE 2.0 集合级加密
官方已明确：随 MongoDB 6.0 发布的 Queryable Encryption 公共预览版（即 FLE 2.0）不再受支持。即使你手动配置了 mongocryptd、schemaMap 和密钥管理，驱动程序在连接 6.0 副本集时会拒绝执行自动加密写入或查询，或直接报错 Auto encryption is not supported for this server version。
- 6.0 的
mongod进程不识别 FLE 2.0 所需的元数据格式和加密命令协议 -
mongocryptd在 6.0 中仅用于旧版 CSFLE（非 Queryable），不支持带索引的加密字段查询 - 所有官方驱动（Node.js/Python/Java 等）在 6.0 连接下会降级为“显式加密”模式，即必须手动调用
encrypt()/decrypt()，无法通过 schema 触发自动行为
在 6.0 副本集上能做的“类 FLE”替代方案
如果你无法升级到 7.0，但又需要字段加密能力，只能退回到客户端显式加密 + 服务端透明存储的组合方式，它不提供查询能力，但可保障静态数据安全：
- 使用驱动提供的
ClientEncryption实例（如 Python 的PyMongo中的ClientEncryption类）手动加密字段值，再写入普通集合 - 加密密钥（DEK）必须由应用层保管，不能依赖 MongoDB 的
keyVault自动管理（6.0 的keyVault仅用于旧版 CSFLE，无 Queryable 支持） - 所有查询必须基于明文条件（如
{"_id": "abc"}），无法按加密字段做find({"ssn": "123-45-6789"})—— 因为该字段在数据库中是密文，且无对应索引 - 务必禁用
autoEncryption选项，否则驱动会尝试协商 FLE 2.0 协议并失败
升级到 MongoDB 7.0 是启用集合级 Queryable Encryption 的唯一路径
7.0 引入了真正的 Queryable Encryption，核心变化包括：
- 移除对
mongocryptd进程的依赖，改用轻量级共享库crypt_shared - 支持在 schemaMap 中定义
encryptMetadata和带contentionFactor的等值查询索引 - 副本集节点无需额外配置即可参与加密流程，只要驱动启用
autoEncryption并提供有效keyVault连接 - 要求驱动版本 ≥ 对应语言的最新稳定版（如 Node.js 驱动 ≥ 6.7.0），且必须使用 Enterprise 或 Atlas 7.0+ 集群
注意：crypt_shared 库必须与 MongoDB 服务端主版本严格匹配（如 7.0.12 需配 7.0.x 的库），混用会导致 libmongocrypt initialization failed 错误。
容易被忽略的关键限制
即使升级到 7.0，Queryable Encryption 在副本集上仍有硬性约束：
- 所有副本集成员必须运行完全相同的 MongoDB 主版本（如全为 7.0.12），小版本不一致可能触发密钥解析失败
- 若使用 KMS（如 AWS KMS/Azure Key Vault），KMS 凭据必须在每个应用节点上可访问，副本集本身不代理或缓存 KMS 调用
- 加密字段不能是分片键、不能出现在
$text索引中、不能用于$lookup的本地字段 -
mongosh仅支持显式加密命令（db.runCommand({encrypt: ...})），不支持通过find()自动加解密，需靠驱动实现
别指望在 6.0 上“打补丁”出 Queryable Encryption——它不是配置问题，而是协议层缺失。真要落地集合级加密查询，7.0 是绕不开的基线。
