必须先将MongoDB Server升级至8.0且featureCompatibilityVersion设为"8.0"，再选用Mongoose 8.5+（捆绑mongodb@6.7.0+）以支持Server 8.0新特性。
直接升级 Mongoose 6 → 8 不可行，必须先升级 MongoDB Server 到 8.0，再匹配兼容的 Mongoose 版本——Mongoose 8.x 仅支持 MongoDB Server 6.0+，且官方明确不兼容 Server 5.x 及更早版本。
确认 MongoDB Server 版本与 featureCompatibilityVersion
升级 Mongoose 前，MongoDB Server 必须已运行在 8.0（或至少 7.0），且 featureCompatibilityVersion 已设为 "8.0" 或 "7.0"。否则 Mongoose 8 的某些新 API（如 findOneAndReplace 的 upsert 行为变更）会触发未定义行为或命令失败。
- 连接任意副本集节点，运行：
db.adminCommand({ getParameter: 1, featureCompatibilityVersion: 1 }) - 所有成员返回
"version": "8.0"才可继续；若仍为"7.0"，需先在主节点执行db.adminCommand({ setFeatureCompatibilityVersion: "8.0" }) - 注意：该命令要求所有数据承载节点在线，且不能降级回
"7.0"—— 一旦设置，不可逆
选择匹配的 Mongoose 版本（不是“最新版”就行）
Mongoose 8.x 本身不直接声明对 MongoDB Server 8.0 的支持等级，它依赖底层 Node.js 驱动（mongodb）。真正起决定作用的是驱动版本。截至 2026 年中，mongodb 驱动 6.7+ 才完整支持 Server 8.0 的新协议特性（如改进的事务语义、changeStream v2 恢复令牌）。
- Mongoose 8.5+ 默认捆绑
mongodb@6.7.0+，可安全用于 Server 8.0 - Mongoose 8.0–8.4 捆绑
mongodb@6.3–6.6，虽能连接，但部分 Server 8.0 新功能（如find().maxTimeMS()在分片集群中的精确生效）可能被忽略 - 不要跳过中间小版本：从 Mongoose 6.13 直接升到 8.5 会丢失大量弃用警告，例如
Model.find().exec()中移除的自动 Promise 包装逻辑，旧代码可能静默失败
处理 Mongoose 6 → 8 的关键破坏性变更
升级后最常出问题的不是连接，而是查询构造和验证逻辑。Mongoose 7 起默认启用严格模式（strict: true），8 进一步收紧了 Schema 解析规则。
-
Schema({ field: { type: String, required: true } })在 6 中允许空字符串通过required校验；8 中空字符串不再满足required，需显式加validate: [v => v !== '', '不能为空'] -
Model.updateOne({ _id }, { $set: { a: 1 } })在 6 中自动包装为$set；8 中若未传$set操作符，会报Cannot update without specifying a single operator - 所有
pre('save')中的this不再是原始 JS 对象，而是 Mongoose Document 实例 —— 若你曾用Object.assign({}, this)提取纯对象，现在必须改用this.toObject({ flattenObjectIds: true })
Server 8.0 的 wire protocol 变更让旧驱动无法识别新错误码，而 Mongoose 8 的错误分类又更细；最容易被忽略的是 writeConcernError 的结构变化——它现在嵌套在 error.writeConcernError 下，而非扁平字段，旧的错误处理逻辑会漏掉这类失败。
