$tostring在聚合中不支持objectid直接转换，因其类型推断弱，仅安全处理字符串、数字等基础类型；需用$convert配onerror/onnull显式转为24位小写十六进制字符串。
为什么 $toString 在聚合中不支持 ObjectId 直接转换？
MongoDB 4.0+ 确实引入了 $toString，但它对 ObjectId 的处理有隐式限制：当字段本身是 ObjectId 类型（如 _id），直接用 $toString: "$_id" 会报错 Expression $toString takes exactly 1 argument 或静默失败——实际是因为旧驱动/Shell 版本未启用完整类型支持，或字段未被正确识别为 ObjectId 实例。
根本原因不是语法错，而是 MongoDB 在聚合上下文中对 ObjectId 的类型推断较弱，$toString 默认只安全处理字符串、数字、布尔、日期、null；ObjectId 需显式“唤醒”其类型信息。
用 $convert + to: "string" 安全转 ObjectId
$convert 是更鲁棒的选择，它明确接受 input 和 to，并能处理 ObjectId。只要确保输入字段确实是 ObjectId 类型（比如来自 $lookup 结果或原始集合的 _id），就能稳定输出十六进制字符串。
- 必须指定
onError和onNull，否则遇到非 ObjectId 值（如 null 或字符串）会中断管道 - 输出格式与
ObjectId.toString()一致，即 24 位小写十六进制字符串，例如"65a7b1c2d3e4f5a6b7c8d9e0" - 在
$match前使用时，建议放在$addFields或$set阶段，避免重复计算
[
{
$set: {
idStr: { $convert: { input: "$_id", to: "string", onError: "", onNull: "" } }
}
},
{ $match: { idStr: "65a7b1c2d3e4f5a6b7c8d9e0" } }
]
匹配外部传入的字符串 ID 时，别在应用层拼接 ObjectId()
常见错误是 Node.js 里这样写：db.collection.aggregate([ { $match: { _id: new ObjectId(req.query.id) } } ]) —— 这看似合理，但若 req.query.id 是无效字符串（如短于 24 位、含非十六进制字符），驱动会抛异常，导致整个聚合失败，且无法在管道内兜底。
- 更稳的做法：先在应用层校验字符串格式（正则
^[0-9a-f]{24}$），再传入聚合 - 或者，在聚合第一阶段用
$cond+$regexMatch过滤非法字符串，再转 ObjectId，避免下游出错 - 注意：MongoDB 本身不提供
$isValidObjectId，得自己模拟，例如{ $regexMatch: { input: "$idParam", regex: "^[0-9a-f]{24}$" } }
性能提示：字符串匹配比 ObjectId 匹配慢，且无法利用 _id 索引
一旦把 _id 转成字符串再匹配，MongoDB 就无法使用默认的 _id 索引——因为索引是按 ObjectId 类型构建的，字符串值不在索引键路径上。
- 如果只是临时调试或小数据量查，影响不大
- 如果高频按字符串 ID 查询，应考虑在写入时冗余存一份
idStr: { $toString: "$_id" }字段，并为其建索引 - 聚合中慎用
$toString或$convert在大集合上做全表转换，CPU 和内存开销明显上升
真正需要字符串匹配的场景，往往说明数据模型里混用了字符串 ID 和 ObjectId ID，这种不一致性比转换本身更值得花时间修正。
