为何Mongoose不推荐将用户自定义对象直接作为查询过滤器？

即使strictQuery设为true，Mongoose只会剔除Schema中不存在的属性，但这不足以覆盖直接传入用户对象（比如req.query）的所有风险，主要原因有以下几点：

• strictQuery不拦截查询操作符
  假设你的Schema里有age字段，用户传入?age[$gt]=18，strictQuery会保留age字段（因为它在Schema中），但不会处理嵌套的$gt操作符。这会导致查询逻辑变成“年龄大于18”，如果是恶意用户传入?password[$ne]=xxx（假设password在Schema中），就可能绕过权限或泄露敏感数据。而sanitizeFilter: true会自动清理这类未经允许的操作符，只保留普通的键值对查询。

• 类型不匹配的隐式转换问题
  比如Schema中age是Number类型，用户传入?age=abc，strictQuery不会校验类型，Mongoose会尝试将字符串转成Number，结果得到NaN，导致查询返回空数据。如果是日期字段，用户传入的非法字符串可能被转换成不符合预期的日期，引发查询结果错误。手动提取字段时，你可以自行做类型校验和转换，避免这类隐式错误。

• 意外的数组查询逻辑
  当用户传入重复参数（比如?name=foo&name=bar），req.query.name会变成数组["foo", "bar"]。Mongoose会自动将数组解析为$in查询（即查找name为foo或bar的文档），但这可能和你预期的“精确匹配单个name”不符。strictQuery不会处理这种情况，因为name是合法字段，但手动提取字段时，你可以控制是否允许数组形式，或者做相应的逻辑处理。

• 敏感字段的权限泄露
  假设你的Schema包含role这类敏感字段，strictQuery会保留该字段（因为它在Schema中），如果用户传入?role=admin，就能直接查询到所有管理员账号，存在数据泄露风险。手动提取字段时，你可以只开放允许用户查询的字段（比如name、age），排除敏感字段，更精准地控制查询范围。

总结来说，strictQuery只是做了“字段是否存在于Schema”的校验，而直接传入用户对象还存在操作符滥用、类型错误、逻辑意外、权限泄露等风险。手动指定查询字段+sanitizeFilter的组合，能更全面地规避这些问题，确保查询的安全性和正确性。

内容的提问来源于stack exchange，提问作者Starbugz