本文详解 mongodb 聚合管道中 `"$match"` 阶段常见构造错误，重点解决因误用 `json.stringify` 导致的查询语法失效问题，并提供安全、规范的参数注入方案。
在使用 MongoDB 聚合管道（Aggregation Pipeline）时，$match 阶段是过滤文档的核心操作。但开发者常因对 JavaScript 对象序列化机制理解偏差，导致生成非法查询结构——如将 { $eq: "params.id" } 错误地转为字符串 '{"$eq":"params.id"}'，使 MongoDB 无法识别操作符，最终查询失败。
❌ 错误写法分析
const pipeline = [
{
$match: {
objectId: JSON.stringify({ $eq: params.id }), // ⚠️ 错误！转成字符串，失去操作符语义
isDeleted: { $ne: true }
}
}
];JSON.stringify({ $eq: params.id }) 输出的是字符串 "{"$eq":"123"}"，而非 BSON 操作符对象。MongoDB 将其视为普通字符串字面量匹配（即 objectId === '{"$eq":"123"}'），完全偏离预期逻辑。
同样，若直接写 objectId: { $eq: params.id } 却未做类型校验或清理，又可能引入 NoSQL 注入 风险（例如 params.id = { $ne: null } 会绕过身份校验）。
✅ 正确且安全的写法
方案一：直传值（适用于已知为安全基础类型）
若 params.id 是可信的字符串/ObjectId/数字（如经 Joi/Yup 校验或从 JWT payload 提取），最简洁方式是：
const pipeline = [
{
$match: {
objectId: params.id, // ✅ 直接匹配值（等价于 { $eq: params.id }）
isDeleted: { $ne: true }
}
}
];MongoDB 默认对字段值执行严格相等匹配，无需显式包裹 $eq。
方案二：显式使用操作符 + 输入净化（推荐用于用户输入）
当 params.id 来自 HTTP 请求体、URL 参数等不可信源时，应先净化、再构造：
npm install mongo-sanitize
const sanitize = require('mongo-sanitize');
const pipeline = [
{
$match: {
objectId: { $eq: sanitize(params.id) }, // ✅ 净化后作为 $eq 值
isDeleted: { $ne: true }
}
}
];? mongo-sanitize 会递归移除所有以 $ 或 . 开头的键名，防止恶意构造 { $where: "1==1" } 或嵌套操作符攻击，同时保留原始数据类型（字符串、数字等）。
方案三：强制转换为 ObjectId（适用于 _id 字段）
若 objectId 实际对应 MongoDB 的 _id 字段（通常为 ObjectId 类型），务必显式转换：
const { ObjectId } = require('mongodb');
// 确保 params.id 是合法 ObjectId 字符串
if (!ObjectId.isValid(params.id)) {
throw new Error('Invalid ObjectId');
}
const pipeline = [
{
$match: {
_id: new ObjectId(params.id), // ✅ 正确匹配 ObjectId
isDeleted: { $ne: true }
}
}
];⚠️ 注意事项总结
- 永远不要对操作符对象调用 JSON.stringify()：它破坏 BSON 结构，仅适用于日志调试，不可用于查询构造。
- 避免手动拼接字符串查询：如 "{ $eq: '" + params.id + "' }"，极易引发注入与语法错误。
-
区分“值匹配”与“操作符匹配”：
- objectId: "abc" → 等价于 { $eq: "abc" }
- objectId: { $in: ["a", "b"] } → 必须保持对象结构
- 聚合管道中 $match 支持完整查询语法，包括 $and、$or、$regex 等，但所有条件都必须是合法 JavaScript/BSON 对象，而非字符串。
遵循以上原则，即可写出既健壮又安全的 MongoDB 聚合查询，彻底规避 [Object] 打印异常与运行时失败问题。
