Go 的嵌入机制本身不必然违反迪米特法则（Law of Demeter），关键在于如何使用被提升的方法与字段：直接调用 u.Tx.Query() 违反该法则，而封装为 u.Query() 则符合——它隐藏实现细节，保障接口稳定性与内部可演进性。
go 的嵌入机制本身不必然违反迪米特法则（law of demeter），关键在于**如何使用被提升的方法与字段**：直接调用 `u.tx.query()` 违反该法则，而封装为 `u.query()` 则符合——它隐藏实现细节，保障接口稳定性与内部可演进性。
在 Go 中，嵌入（embedding）是一种强大的组合机制，用于复用结构体字段和方法。但其与面向对象中“继承”的语义不同：嵌入类型的方法会被提升（promoted） 到外层类型，调用时 receiver 仍是嵌入类型自身。这带来便利的同时，也引发对设计原则的审视——尤其是迪米特法则（LoD），即“只与直接朋友交谈”，强调避免暴露内部组成结构、减少模块间耦合。
以如下常见嵌入为例：
type User struct {
Name string
Password string
*sql.Tx // 嵌入导出类型 *sql.Tx
}
若客户端代码写作：
rows, err := u.Query("SELECT * FROM users") // ✅ 合理：调用提升方法，不暴露 Tx
// vs
rows, err := u.Tx.Query("SELECT * FROM users") // ❌ 违反 LoD：显式依赖嵌入细节
前者完全符合迪米特法则：u.Query() 是 User 的公开行为契约，无论底层是通过嵌入 *sql.Tx、持有私有 tx *sql.Tx 字段，还是未来改用连接池或 ORM 封装，只要 User.Query() 接口不变，所有调用方均无需修改。
而后者 u.Tx.Query() 则严重违反 LoD：它将 User 的内部实现（即“它包含一个 *sql.Tx”）暴露给外部，使调用方与 sql.Tx 的具体 API 紧密耦合。一旦 User 结构重构（如移除嵌入、改为组合或抽象为接口），所有此类调用将立即失效，破坏封装性与可维护性。
✅ 正确实践：封装而非暴露
推荐采用显式委托 + 私有字段的方式，兼顾清晰性、可控性与演进自由度：
type User struct {
Name string
Password string
tx *sql.Tx // 小写首字母 → 非导出，完全隐藏实现
}
// 显式定义业务语义方法，而非依赖提升
func (u *User) Query(query string, args ...interface{}) (*sql.Rows, error) {
if u.tx == nil {
return nil, errors.New("database transaction not initialized")
}
return u.tx.Query(query, args...)
}
func (u *User) Exec(query string, args ...interface{}) (sql.Result, error) {
if u.tx == nil {
return nil, errors.New("database transaction not initialized")
}
return u.tx.Exec(query, args...)
}
此设计优势显著：
- LoD 合规：调用方仅依赖 User 自身方法，不感知 sql.Tx；
- 空值安全：可在方法内统一校验 u.tx 是否有效；
- 可测试性强：易于 mock User 行为，无需构造真实 *sql.Tx；
- 演进友好：未来可无缝替换底层数据访问层（如切换至 pgx 或添加重试逻辑），只需修改 User 内部实现。
⚠️ 注意事项：
- 若嵌入的是未导出类型（如 struct{ db *sql.DB }），则不会造成 LoD 违反，因为外部无法访问其字段或方法；
- LoD 并非禁止所有间接调用，而是反对“链式导航”（a.b().c().d()）和“穿透式访问”（a.field.method()）；
- 它不解决 API 不兼容变更（如 sql.Tx.Query 被删除），而是确保：当 User 内部重构时，调用 u.Query() 的代码无需改动——这才是 LoD 的核心价值。
总结：嵌入是 Go 的语法特性，不是设计缺陷；是否违反迪米特法则，取决于你如何组织接口与使用方式。坚持“为业务建模，而非为实现建模”，用显式方法封装行为、隐藏数据细节，就能在享受嵌入便利的同时，坚守松耦合、高内聚的工程准则。
