$lookup是MongoDB聚合管道中用来实现跨集合关联的核心操作符，用法上类似于关系型数据库的join。不过很多使用者在实际开发中会遇到一个诡异的现象：两个集合里明明存在可以对应的数据，$lookup执行完之后unwind出来的结果却永远是空数组。排查半天索引、集合名、字段名都没问题，最后才发现是localField和foreignField存储的数据类型不一致导致的。MongoDB在匹配关联字段时执行的是严格相等比较，NumberLong类型的1和String类型的'1'在它眼里完全是两个值，这种类型差异在Schema设计不规范的系统里尤其常见。
为什么类型不一致会导致$lookup匹配不到数据
MongoDB是弱Schema的文档数据库，同一个字段在不同文档中可以存储不同的类型。这种灵活性带来了便利，也埋下了类型混乱的隐患。BSON类型系统在比较时遵循严格匹配原则：数值类型内部有隐式转换规则（比如int32的1和double的1.0可以相等），但数值和字符串之间、ObjectId和字符串之间是绝对不相等的。
举个典型的场景：订单集合orders里存的是userId字段，值是ObjectId类型；而用户表users在早期设计时_id虽然是ObjectId，但有些老数据通过脚本导入时_id被存成了字符串。执行$lookup时指定localField为userId、foreignField为_id，那些_id为字符串类型的用户文档就永远匹配不上，表现为部分订单关联得到用户、部分关联不到。
更隐蔽的情况是NumberLong和NumberInt混用。驱动程序在不同语言下写入数值的默认类型不同，Java驱动写入Long对应NumberLong，而Python的pymongo写入int默认是NumberInt，超过一定范围才是NumberLong。这两种数值类型之间可以互相匹配，但一旦有一方是字符串形式的数字，匹配就彻底失败了。
如何快速定位类型差异
解决之前先要确认问题确实出在类型上。最直接的方式是写一个简单的聚合，用$type运算符查看字段的实际BSON类型分布。
db.orders.aggregate([
{
$group: {
_id: { $type: "$userId" },
count: { $sum: 1 }
}
}
])
// 如果输出中出现 "objectId" 和 "string" 两种类型，说明类型确实不统一同样对被关联集合执行一次检查：
db.users.aggregate([
{
$group: {
_id: { $type: "$_id" },
count: { $sum: 1 }
}
}
])除了$type，还可以用$addToSet抽样几条具体的文档对比肉眼确认。如果类型分布显示两种类型并存，就要先决定以哪种类型为准，再做统一转换。一般来说，如果其中一方无法统一改造（比如关联的是系统内置的_id字段），就以不可变的一方为标准，去转换另一方。
用类型转换操作符在$lookup前预处理
从MongoDB 4.0开始，管道中可以使用$toObjectId、$toString、$toInt等类型转换操作符，在执行$lookup之前先用$project或$addFields把字段转换成统一类型，这是最常用的解法。
假设orders.userId是字符串，而users._id是ObjectId，处理方式如下：
db.orders.aggregate([
{
$addFields: {
userIdObj: { $toObjectId: "$userId" } // 把字符串转成ObjectId
}
},
{
$lookup: {
from: "users",
localField: "userIdObj",
foreignField: "_id",
as: "userInfo"
}
}
])需要注意$toObjectId对非法字符串会直接报错，比如userId里混有空字符串或者格式不合法的字符串，聚合会中断。稳妥的做法是改用$convert并指定onError默认值，保证脏数据不会让整个查询崩掉。
db.orders.aggregate([
{
$addFields: {
userIdObj: {
$convert: {
input: "$userId",
to: "objectId",
onNull: null, // 输入为null时返回null
onError: null // 转换失败时返回null而不是报错
}
}
}
},
{
$lookup: {
from: "users",
localField: "userIdObj",
foreignField: "_id",
as: "userInfo"
}
}
])反向的情况，即需要把字符串数字和数值做匹配，可以用$toInt或$convert配合to: "int"处理。这里有个细节：$toInt能处理的字符串范围有限，超范围会报错，遇到可能超界的字段用$toLong或者统一转成double更安全。
let加pipeline写法：更灵活的关联控制
如果不想在主集合上做字段投影，或者需要在关联条件里做更复杂的逻辑，可以使用$lookup的let加pipeline形式，在pipeline内部对foreignField做转换。
db.orders.aggregate([
{
$lookup: {
from: "users",
let: { orderUserId: "$userId" },
pipeline: [
{
$match: {
$expr: {
$eq: [
"$_id",
{ $toObjectId: "$$orderUserId" }
]
}
}
}
],
as: "userInfo"
}
}
])这种写法的好处是主文档结构完全不被改动，转换逻辑集中在子管道里。但它的代价也很明显：$expr形式的匹配无法有效利用被关联集合_id上的索引，当users集合数据量大时性能会明显下降。官方经典$lookup形式因为可以转化为底层索引查找，性能通常好得多。
所以生产环境下的选择原则是：数据量小或者临时分析场景用let加pipeline灵活处理；核心业务链路尽量在$lookup之前用$addFields转换主集合字段，保持经典写法让索引生效。
治本方案：批量修正存量脏数据
前几种方法都属于查询时补救，每次查询都要多执行一次转换。如果类型混乱是普遍现象，更好的做法是把存量数据一次性清洗统一。批量转换可以用updateMany配合聚合管道更新（MongoDB 4.2以上支持）。
// 把users集合里字符串类型的_id统一转成ObjectId
// 注意_id不能直接update，需要遍历处理
db.users.find({ _id: { $type: "string" } }).forEach(function(doc) {
db.users.deleteOne({ _id: doc._id });
db.users.insertOne({ ...doc, _id: ObjectId(doc._id) });
});
// 普通字段的批量转换可以用管道更新
db.orders.updateMany(
{ amount: { $type: "string" } },
[
{ $set: { amount: { $toDecimal: "$amount" } } }
]
)清洗完成后，还应该在应用层加约束，写入前统一做类型校验，比如在写入前把所有id字段统一转成ObjectId再落库，避免脏数据再次累积。同时给关联字段建好索引，保证$lookup的匹配阶段能走索引扫描。
总结一下处理思路：先用$type确认类型差异，短期用$addFields加类型转换操作符在查询层兼容，长期通过数据清洗和写入校验根治问题，性能敏感的场景避免let加pipeline而优先选择可走索引的经典$lookup写法。按这个顺序排查和处理，$lookup关联为空的问题基本都能解决。