mongodb 6.0 的 queryable encryption 是不兼容、已弃用的预览功能，无法安全启用：密钥与元数据格式和7.0 ga版互不识别，升级后原有加密字段不可解密或查询；其依赖的mongocryptd不执行加解密，且驱动支持不完整，错误提示模糊，无服务器端校验机制。
MongoDB 6.0 中的 Queryable Encryption 是预览功能，**不推荐在生产环境启用**——它与 MongoDB 7.0+ 的正式版（GA）完全不兼容，且自 2026 年 4 月起已被官方明确弃用并存档。
为什么 MongoDB 6.0 的 Queryable Encryption 无法安全启用
6.0 的 Queryable Encryption 是实验性实现，核心限制包括：
- 密钥格式、元数据结构和查询协议与 7.0 GA 版本互不识别；升级到 7.0 后，所有 6.0 加密字段将无法解密或查询
- 驱动层依赖
mongocryptd进程，但该进程在 6.0 中仅做语法校验和字段标记，**不参与实际加解密**，而真正执行加密的libmongocrypt库在 6.0 驱动中对 Queryable Encryption 的支持不完整 - 错误信息模糊，常见报错如
AutoEncryptionError: failed to create data key往往源于kmsProviders字段缺失（例如 AWS 临时凭证漏掉sessionToken），但日志不会指出具体缺哪一项 - 没有服务器端强制策略：即使配置了自动加密规则，
mongod不校验写入是否真被加密，也无法阻止绕过驱动直连的未加密写入
如果仍需在 6.0 环境处理敏感字段，应改用 CSFLE
客户端字段级加密（CSFLE）是 6.0 唯一受支持、可落地的字段级保护方案。关键实操点：
- 必须使用
mongocryptd（6.0 Enterprise 或 Atlas 6.0+ 集群自带），启动前确认其在PATH中可执行；否则驱动会静默降级为不加密写入 - 加密模式选择直接影响查询能力：
deterministic支持等值查询，random更安全但仅支持解密，不可查；二者不能混用于同一字段 -
autoEncryption配置中keyVaultNamespace必须与 KMS 创建的密钥集合路径一致，例如"encryption.__keyVault"，拼错会导致KeyNotFound错误 - 驱动版本必须匹配：Node.js 驱动需 v4.13+，Python 驱动需 v4.6+；旧版驱动可能忽略
schemaMap或错误解析encryptExpression
mongocryptd 启动失败或不生效的典型原因
即使安装了 Enterprise 版，mongocryptd 也常因权限或路径问题静默退出：
- Linux 下若以非 root 用户运行应用，
mongocryptd默认绑定127.0.0.1:27020，但可能被 SELinux 或防火墙拦截；可用netstat -tuln | grep 27020验证端口是否监听 - Windows 上若 MongoDB 安装在含空格路径（如
C:\Program Files\），mongocryptd可能因路径解析失败直接退出，建议重装至无空格路径 - 配置
kmsProviders时，AWS 提供商必须包含accessKeyId、secretAccessKey和（若使用 STS 临时凭证）sessionToken；Azure 则必须提供tenantId、clientId、clientSecret和identityPlatformEndpoint - 不要尝试手动启动
mongocryptd --config /path/to/config.yaml：6.0 驱动默认不读取外部配置文件，而是通过 IPC 传递参数，手动启动反而导致端口冲突
6.0 的 Queryable Encryption 已成技术死胡同——它没留下迁移路径，也不提供向后兼容的密钥轮换机制。真要落地机密计算，唯一可行路径是升级到 MongoDB 7.0+ 并使用 GA 版 Queryable Encryption，或者退守 CSFLE 并接受其确定性加密带来的可查询性妥协。
