本文详解如何在 go 的 mgo 驱动中正确处理 mongodb 文档间关系，推荐使用 objectid 引用 + 封装查询方法的模式，避免嵌套冗余、兼顾性能与可维护性。
在 MongoDB 这类文档型数据库中，“关系”并非通过外键强制约束，而是由应用层设计决定——是嵌入（Embedding）还是引用（Referencing）。mgo 作为底层驱动（非 ORM），不提供自动关联加载、懒加载或关系映射等高级功能，因此需开发者主动设计清晰、可读且高效的关系模型。
✅ 推荐实践：引用式建模 + 方法封装
如问题中第二种方式所示，将 Friends 字段定义为 []bson.ObjectId 是符合 MongoDB 设计哲学的合理选择：
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 字段设为小写（friends 而非 Friends），使其成为未导出字段，既避免意外暴露给外部 API，又可通过自定义方法统一管控访问逻辑。
接着，为 User 类型添加一个语义清晰的 Friends() 方法，负责按 ID 批量查出完整用户数据：
func (u *User) Friends(session *mgo.Session) ([]User, error) {
if len(u.friends) == 0 {
return []User{}, nil
}
var users []User
err := session.DB("your_db").C("users").Find(bson.M{
"_id": bson.M{"$in": u.friends},
}).All(&users)
return users, err
}✅ 优势总结：
- 解耦清晰：结构体只存引用（ID），业务逻辑与数据存储分离；
- 可读性强：调用 user.Friends(sess) 即知意图，无需阅读字段类型猜测用途；
- 灵活可控：可按需决定是否加载（避免 N+1 查询）、添加排序/分页/过滤；
- 符合 Go 习惯：用方法封装副作用（DB 查询），而非依赖反射或魔法字段。
⚠️ 注意事项与进阶建议
- 避免循环引用：若 User 同时有 friends 和 followers 字段，需谨慎设计查询边界，防止无限递归调用。
- 批量查询优化：$in 查询在 ID 数量极多（如 >1000）时可能影响性能，可考虑分批或引入缓存层。
- 事务与一致性（MongoDB 4.0+）：若需保证“添加好友 + 更新双方 friends 列表”的原子性，应启用会话事务，并确保使用支持事务的存储引擎（WiredTiger）。
- 迁移提醒：从嵌入式（第一种方式）迁移到引用式时，务必编写迁移脚本提取并去重 ID，避免数据丢失。
总结
mgo 不提供 ORM 式的关系管理，这恰是其轻量与可控的体现。真正的“关系意识”应体现在代码设计中：用私有 ID 字段表达引用意图，用公开方法封装关联查询逻辑。这种模式既尊重 MongoDB 的文档本质，又保持 Go 代码的明确性与可测试性——不是“让框架替你思考”，而是“用简洁的代码讲清楚你的数据故事”。
