本文介绍在使用 mgo 驱动时，如何针对结构体指针字段（如 `*tool`）实现区别于值类型字段的自定义 bson 序列化逻辑，避免默认内联嵌套，转而仅存储引用 id。
在 MongoDB 的 Go 生态中，mgo（尽管已归档，但仍在许多遗留项目中广泛使用）默认将结构体值和结构体指针统一按内联方式序列化为嵌套 BSON 文档。这意味着如下结构：
type Tool struct {
ID bson.ObjectId `bson:"_id,omitempty"`
Name string `bson:"name"`
}
type Order struct {
Item Tool `bson:"item"`
AssociatedItem *Tool `bson:"associated_item"` // ❌ 默认仍会完整嵌入整个 Tool 文档
}即使 AssociatedItem 是 *Tool，mgo.Marshal() 仍会将其解引用后完整序列化为子文档，而非你期望的“仅存 ID 引用”。而 SetBSON() / GetBSON() 接口作用于类型层面（如 Tool），*无法区分 Tool 和 `Tool的序列化行为**——这是mgo` 类型系统的设计限制。
✅ 推荐方案：通过类型别名实现语义隔离
最简洁、无侵入、符合 Go 类型安全原则的方式是：为需特殊序列化的指针场景，定义独立的类型别名，并为其单独实现 SetBSON/GetBSON。
// 定义新类型，语义上表示“可选择性序列化的 Tool 引用”
type SelectiveTool Tool
// 实现 GetBSON：当作为 *SelectiveTool 字段时，只输出 ID（或自定义引用格式）
func (st *SelectiveTool) GetBSON() (interface{}, error) {
if st == nil {
return nil, nil
}
return bson.M{"_id": (*Tool)(st).ID}, nil // 仅存 ObjectId
}
// 实现 SetBSON：从 BSON 反序列化时，仅解析 _id 并初始化空 Tool（或按需加载）
func (st *SelectiveTool) SetBSON(raw bson.Raw) error {
var m bson.M
if err := raw.Unmarshal(&m); err != nil {
return err
}
if id, ok := m["_id"]; ok {
if oid, ok := id.(bson.ObjectId); ok {
*st = SelectiveTool{ID: oid} // 仅恢复 ID，其他字段留空
}
}
return nil
}
// 更新 Order 结构体，明确使用新类型
type Order struct {
Item Tool `bson:"item"`
AssociatedItem *SelectiveTool `bson:"associated_item"` // ✅ 现在会触发自定义序列化
}⚠️ 注意事项与最佳实践
- 零值安全：*SelectiveTool 为 nil 时，GetBSON() 应返回 nil，MongoDB 将存储 null，符合引用语义；
- 反序列化灵活性：SetBSON 中可根据实际需求扩展逻辑，例如：从 _id 加载完整 Tool（需额外 DB 查询），或仅缓存 ID 供后续懒加载；
- 避免循环依赖：若 SelectiveTool 需访问业务逻辑（如 DAO），建议通过组合而非嵌入传递依赖，保持类型纯净；
- 迁移兼容性：旧数据中若 associated_item 是完整嵌套文档，SetBSON 可增强容错逻辑（先尝试解析 _id，失败则 fallback 到完整 Tool 解析）；
-
替代方案对比：
- ❌ 使用 bson.ObjectId 字段：丢失类型信息与业务语义，需手动转换；
- ❌ 在 Order 中实现 GetBSON：破坏单一职责，且难以复用；
- ✅ 类型别名 + 自定义编组：语义清晰、可复用、零运行时开销、完全类型安全。
通过该模式，你能在保持代码可读性与类型安全的同时，精准控制指针字段的持久化形态——从“全量嵌套”转向“轻量引用”，为构建松耦合、可扩展的 MongoDB 数据模型奠定基础。
