mgo 作为 mongodb 的 go 驱动，不提供 orm 式的自动关联加载；推荐采用“id 引用 + 显式查询”模式——即结构体中存储 `[]bson.objectid`，再通过封装方法按需查库填充完整对象。
在 MongoDB 这类文档型数据库中，“关系”并非通过外键约束实现，而是依赖应用层的设计策略。mgo 作为底层驱动，本身不支持自动嵌套加载、延迟关联或声明式关系映射（如 GORM 或 Django ORM 那样）。因此，正确的做法是权衡数据一致性、查询性能与代码可维护性，选择适合场景的引用模型。
✅ 推荐方案：ID 引用 + 方法封装
将 Friends 字段定义为 []bson.ObjectId（私有字段），并提供一个显式的 Friends() 方法完成关联查询：
type User struct {
Id bson.ObjectId `json:"_id,omitempty" bson:"_id,omitempty"`
Username string `json:"username" bson:"username"`
Email string `json:"email" bson:"email"`
Password string `json:"password" bson:"password"`
friends []bson.ObjectId `json:"-" bson:"friends"` // 私有字段，不导出，不参与 JSON 序列化
}
// Friends 返回该用户所有好友的完整 User 实例列表
func (u *User) Friends(session *mgo.Session) ([]User, error) {
if len(u.friends) == 0 {
return []User{}, nil
}
var friends []User
err := session.DB("your_db").C("users").Find(bson.M{
"_id": bson.M{"$in": u.friends},
}).All(&friends)
return friends, err
}调用示例：
session := session.Copy()
defer session.Close()
var user User
err := session.DB("your_db").C("users").FindId(userID).One(&user)
if err != nil {
log.Fatal(err)
}
// 按需加载好友（显式、可控、无隐式 N+1）
friendList, err := user.Friends(session)
if err != nil {
log.Fatal(err)
}
fmt.Printf("Found %d friends\n", len(friendList))⚠️ 注意事项与最佳实践
- 避免嵌套文档（Approach #1）：将完整 User 结构体嵌入 Friends 字段会导致数据冗余、更新不一致（如好友改名需同步多处）、文档膨胀，且违背 MongoDB 的“单文档高内聚”设计哲学。
- ID 引用更灵活：[]bson.ObjectId 占用空间小、索引高效，支持跨集合引用（如 Post.AuthorID → User._id），也便于构建图谱类查询（如“共同好友”）。
- 警惕 N+1 查询：不要在循环中对每个 ID 单独 FindId()；务必使用 $in 批量查询（如上例），并注意 $in 数组长度限制（默认 10MB BSON 大小，实际建议 ≤ 1000 个 ID）。
-
考虑使用聚合管道（Aggregation）：对于复杂关联（如带条件/分页的好友列表），可用 $lookup 在服务端完成左连接，减少往返次数：
pipe := session.DB("your_db").C("users").Pipe([]bson.M{ {"$match": bson.M{"_id": userID}}, {"$lookup": bson.M{ "from": "users", "localField": "friends", "foreignField": "_id", "as": "friend_docs", }}, })
✅ 总结
mgo 不是 ORM，它的定位是轻量、高性能的 MongoDB 原生驱动。所谓“关系”，本质上是应用逻辑的一部分：用 ID 表达关联，用方法封装获取逻辑，用批量查询保障效率。这种显式、透明、可控的方式，反而更契合 Go 的工程哲学——不隐藏复杂度，只提供清晰的抽象边界。
