如何为具有相同字段的多个 Go 结构体统一实现 Save 方法

在 Go 中，当多个结构体共享一个关键字段（如主键 guid）并需复用相同逻辑（如自动生成 id 并插入数据库）时，可通过接口抽象或嵌入结构体 + 接口约束实现安全、可维护的 sa ve 方法复用，避免重复代码且兼容 beego/orm。

在 Go 中，当多个结构体共享一个关键字段（如主键 guid）并需复用相同逻辑（如自动生成 id 并插入数据库）时，可通过接口抽象或嵌入结构体 + 接口约束实现安全、可维护的 sa ve 方法复用，避免重复代码且兼容 beego/orm。

先说几个核心判断：Go 语言没有传统面向对象中的“继承”或“mixin”，但它提供了更清晰、更显式的组合机制——接口（Interface）和结构体嵌入（Embedding）。回到实际场景：ModelA 和 ModelB 都包含一个 Guid string`orm:"pk"` 字段，并且它们的 Sa ve() 逻辑几乎完全一致——生成 GUID，赋值，然后调用 o.Insert(this)。怎么用最地道的方式把这部分重复代码收拢起来？这里有两个成熟方案可以参考。

✅ 方案一：定义公共接口 + 为各结构体独立实现（推荐，最清晰、零耦合）

这是最符合 Go 惯用法的做法：把行为契约明牌打出去，没有隐式依赖，和 ORM 的兼容性也最彻底。

// 定义 Sa vable 接口，声明 Sa ve 行为
type Sa vable interface {
    Sa ve() error
}

// 为 ModelA 实现 Sa ve —— 注意：接收者必须是 *ModelA 才能修改字段
func (m *ModelA) Sa ve() error {
    o := orm.NewOrm()
    m.Guid = guidlib.Generate() // 直接赋值，无需复制
    _, err := o.Insert(m)
    return err
}

// 为 ModelB 实现 Sa ve —— 同样使用 *ModelB 接收者
func (m *ModelB) Sa ve() error {
    o := orm.NewOrm()
    m.Guid = guidlib.Generate()
    _, err := o.Insert(m)
    return err
}

✅ 优势：

• 每个模型完全自治，Sa ve() 可以自由定制——比如后续加上日志、校验之类，完全不受影响；
• o.Insert(m) 传入的是完整结构体，ORM 能正确识别所有字段（FiledA / FiledB 都能纳进去）；
• 多态调用非常自然：

func Persist(s Sa vable) error {
    return s.Sa ve() // 统一调用入口
}
Persist(&modelA) // OK
Persist(&modelB) // OK

⚠️ 方案二：嵌入基础结构体（谨慎使用）

如果字段和逻辑高度一致，且未来基本不需要差异化，嵌入也是一种选择。不过，得清楚它的边界在哪里。

type BaseModel struct {
    Guid string `orm:"pk"`
}

type ModelA struct {
    BaseModel // 嵌入，非继承
    FiledA    string
}

type ModelB struct {
    BaseModel
    FiledB string
}

// 为 BaseModel 实现 Sa ve —— 注意：接收者是 *BaseModel，但 Insert 时需传入具体类型！
func (b *BaseModel) Sa ve(sa vable interface{}) error {
    o := orm.NewOrm()
    b.Guid = guidlib.Generate()
    _, err := o.Insert(sa vable) // 关键：传入 *ModelA 或 *ModelB 实例，而非 *BaseModel
    return err
}

// 使用示例：
// a := &ModelA{FiledA: "test"}
// a.Sa ve(a) // 显式传入自身，确保 ORM 插入完整结构体

⚠️ 重要限制与注意事项：

• o.Insert(b) ❌ 会失败——因为 *BaseModel 不包含 FiledA / FiledB，ORM 只看到 Guid；
• 必须把具体结构体指针（*ModelA）作为参数传入 Sa ve()，这破坏了方法调用的自然性——怎么说呢，用起来有点别扭；
• 嵌入模式更适合“共用行为 + 不可变字段”的场景，而 ORM 模型这种需要完整结构体参与序列化的情形，不太建议硬套。

? 最佳实践总结

1. 优先选择接口实现：每个模型单独写一个 Sa ve()，代码量其实很少（就那么 3 行差异），语义明确，ORM 兼容性 100%。多数生产项目里，这个方案都是最优解；
2. 警惕“伪继承”陷阱：别想着让 BaseModel.Sa ve() 去处理所有子类型——Go 的嵌入不是继承，*BaseModel 在 ORM 眼里就是 *BaseModel，完全不是 *ModelA；
3. 可测试性自然就来了：接口天然便于 mock，比如 Sa vable 接口可以被测试桩轻松实现；
4. 扩展思路：如果 Sa ve 逻辑持续变复杂（事务、钩子、重试机制等），还可以考虑封装成通用函数：

func Sa veWithGUID[T interface{ SetGUID(string) }](o orm.Ormer, model T) error {
    guid := guidlib.Generate()
    model.SetGUID(guid)
    _, err := o.Insert(model)
    return err
}
// 需为 ModelA/ModelB 添加 SetGUID 方法（轻量适配）

总而言之，遵循“接口优先、显式优于隐式”这条原则，既能消除重复代码，也能写出一套地道、健壮、容易演进的 Go ORM 层。从实践来看，这比硬套嵌入方案要靠谱得多。