strictQuery 默认值由 false 变为 true 是 Mongoose 6.0+ 升级后最常触发警告的根源，导致 find 等查询因字段名不匹配而失效；修复应统一查询字段与 schema 字段，而非关闭 strictQuery。
strictQuery 默认值变更是 Mongoose 6.0+ 升级后最常触发警告的根源，不是代码写错了，是配置语义变了。
strictQuery 警告出现时，find、findOne 等查询突然不生效？
这是典型表现：查询条件里写了 status: "draft"，但集合里字段实际叫 state，旧版 Mongoose 默默忽略这个错字段；新版则抛出 strictQuery is false 警告，并可能返回空结果——因为字段名不匹配导致查询条件被过滤掉。
- 根本原因：
strictQuery默认从false（Mongoose true（Mongoose ≥ 6.0） - 影响范围：所有带对象字面量条件的
find、findOne、updateOne等操作 - 别误判成 schema 定义问题——即使 schema 里没定义
status，只要查询时传了，strictQuery: true就会拒绝它 - 临时验证方法：在查询前加
console.log(JSON.stringify(queryObj))，确认传进去的键名是否和 schema 字段一致
怎么关掉 strictQuery 警告（不推荐但有时必须）
如果你正在迁移老项目，短期无法改全查询逻辑，可以显式降级行为，但得清楚代价：
- 在连接时设置：
mongoose.set('strictQuery', false)，必须在mongoose.connect()前调用 - 或在 schema 级覆盖：
new Schema({ ... }, { strictQuery: false })，只影响该 model - ⚠️ 风险：掩盖字段名拼写错误，后期排查更难；且
strictQuery: false在未来版本可能被移除 - 注意：这不是“关闭校验”，而是退回到旧版宽松模式；
strict（控制 save 时字段）和strictQuery是两个独立开关
真正修复：让查询字段和 schema 字段对齐
这才是长期可维护的做法。常见场景和对应动作：
- API 接收的参数字段名和数据库字段不一致（比如前端传
user_id，schema 定义为userId）：在进 query 前做映射，别直接把 req.query 往find()里塞 - 历史数据有冗余字段（如同时存在
status和state）：用$or或聚合管道处理，而不是依赖strictQuery: false让 Mongoose 自动忽略 - 使用了
lean()后字段缺失：lean 不影响strictQuery，但容易让人误以为是 lean 导致的——先确认是不是查询条件本身字段就不对 - 检查
toObject()和toJSON()的transform是否干扰了查询逻辑（它们不影响查询，但可能误导你查哪张表）
升级后其他易踩的坑（顺手一提）
Mongoose 6/7 升级还连带几个隐性变化，排查时别只盯着 strictQuery：
-
findOneAndUpdate默认不返回新文档了：必须显式加{ new: true }，否则行为和以前相反 -
required: true在嵌套 schema 里现在更严格，空对象{}不再被跳过校验 - 连接字符串里的
useNewUrlParser和useUnifiedTopology已废弃，删掉它们不会报错，但会收到 deprecation warning - 如果用了
mongoose.plugin()，确保插件没依赖已移除的内部 API（比如Schema.prototype.methods的早期写法）
strictQuery 只是冰山露出的一角，真正麻烦的是那些没报错、但结果不对的查询——它们往往发生在字段映射层，而不是 Mongoose 本身。
