本文详解如何在 Go 语言中使用 mgo 驱动正确构造含 $geoWithin、$center 数组参数及时间条件的 MongoDB 查询，重点解决 []interface{} 类型转换、时间单位误用等常见陷阱。
本文详解如何在 go 语言中使用 mgo 驱动正确构造含 `$geowithin`、`$center` 数组参数及时间条件的 mongodb 查询，重点解决 `[]interface{}` 类型转换、时间单位误用等常见陷阱。
在使用 mgo（现已归档，但仍在维护项目中广泛使用）与 MongoDB 交互时，将 Shell 查询准确映射为 Go 的 bson.M 结构是关键。尤其当查询涉及地理空间操作（如 $geoWithin + $center）时，Go 对数组类型的严格类型要求容易引发运行时错误或查询无结果。
核心问题在于：MongoDB 的 $center 接受形如 [[lng, lat], radius] 的二维数组，而 Go 的 bson.M 无法直接接受 Go 原生切片（如 [][]float64 或 []struct{}），必须显式声明为 []interface{} 类型，以确保 bson 库能正确序列化为 BSON 数组。
✅ 正确写法如下：
q := bson.M{
"location": bson.M{
"$geoWithin": bson.M{
"$center": []interface{}{
j.Location.Coordinates, // 假设 j.Location.Coordinates 是 []float64{lon, lat} 或 [2]float64
5000, // 半径（单位：米）
},
},
},
"expirationtimems": bson.M{
"$gte": time.Now().UnixMilli(), // ✅ 推荐：直接使用 UnixMilli() 获取毫秒时间戳
// ❌ 错误示例：time.Now().Unix() * 1000 可能因 int64 溢出或精度丢失导致逻辑错误
// 若环境不支持 Go 1.17+，可用：time.Now().Unix()*1e3 + int64(time.Now().Nanosecond()/1e6)
},
"_id": bson.M{
"$gte": p, // 注意：_id 为字符串时，$gte 按字典序比较；确保 p 格式兼容（如 ObjectIdHex 或同类型字符串）
},
}
// 执行查询（含排序与限制）
iter := collection.Find(q).Sort("_id").Limit(50).Iter()
⚠️ 关键注意事项：
- $center 数组必须为 []interface{}：即使 j.Location.Coordinates 是 []float64，也需整体包裹为 []interface{}，否则 mgo 会忽略该字段或报错。
- 时间戳单位务必统一：MongoDB 中 expirationtimems 字段名已暗示单位为毫秒（ms），应使用 time.Now().UnixMilli()（Go 1.17+）；若使用旧版 Go，避免 Unix() * 1000（可能因 Unix() 返回秒级整数，乘法后仍为秒级，非毫秒）。
- _id 字符串比较需谨慎：$gte 对字符串执行字典序比较。若 _id 是 ObjectId（如 "2a920240836c40d8b374203a798a27fa.16"），确保所有 ID 遵循相同格式（如时间前缀 + 点分序号），否则排序不可靠。更健壮的方式是使用 ObjectIdHex 或存储为 ObjectId 类型。
- 地理坐标顺序：MongoDB 要求 GeoJSON 和 legacy coordinate pairs 均为 [longitude, latitude]（注意：不是 [lat, lng]）。请确认 j.Location.Coordinates 为 [ -73.94075, 40.789138 ] 格式。
? 小结：mgo 的 bson 序列化依赖显式接口类型，地理查询需严格遵循坐标顺序与数组封装规范，时间字段须匹配实际存储单位。迁移至官方 MongoDB Go Driver（go.mongodb.org/mongo-driver/mongo）可获得更好类型安全与维护支持，但上述原则在新驱动中同样适用（仅语法略有差异）。
