Go 的嵌入机制本身不必然违反迪米特法则（Law of Demeter），关键在于如何使用被提升的方法与字段：直接访问嵌入类型的导出字段（如 u.Tx.Query()）属于违反；而通过外层类型统一接口调用（如 u.Query()）则符合封装原则，满足迪米特法则。
go 的嵌入机制本身不必然违反迪米特法则（law of demeter），关键在于**如何使用被提升的方法与字段**：直接访问嵌入类型的导出字段（如 `u.tx.query()`）属于违反；而通过外层类型统一接口调用（如 `u.query()`）则符合封装原则，满足迪米特法则。
在 Go 中，嵌入（embedding）是一种强大的组合机制，它允许一个结构体“继承”另一个类型的方法和字段（称为提升，promotion）。但这种便利性容易模糊职责边界——尤其当嵌入的是导出类型（如 *sql.Tx）时，外部代码可能无意中依赖其内部实现细节。
例如，以下写法看似简洁，实则埋下耦合隐患：
type User struct {
Name string
Password string
*sql.Tx // 导出的嵌入字段
}
// ❌ 违反迪米特法则：暴露了 User 内部依赖 sql.Tx 的实现细节
u.Tx.Query("SELECT * FROM users")此处 u.Tx.Query() 显式穿透了 User 的抽象边界，将客户端与 sql.Tx 的具体存在强绑定。一旦 User 改为持有 *sql.DB、或改用 ORM 封装、甚至完全移除事务依赖，所有调用 u.Tx.Query() 的代码都需同步修改——这正是迪米特法则旨在避免的“过度了解”。
✅ 正确做法是隐藏实现，暴露契约：通过方法签名统一对外提供能力，无论底层是嵌入、组合还是完全重写：
type User struct {
Name string
Password string
tx *sql.Tx // ✅ 非导出字段，彻底隐藏实现
}
// ✅ 符合迪米特法则：客户端只知 User.Query()，不知也不需知其如何实现
func (u *User) Query(query string, args ...interface{}) (*sql.Rows, error) {
return u.tx.Query(query, args...)
}
// 使用方式（安全、稳定、可演进）
rows, err := u.Query("SELECT name FROM users WHERE id = ?", 123)此时，即使未来重构 User：
- 将 tx 替换为 db *sql.DB 并改用 db.Query()；
- 或引入中间层 transactionExecutor；
- 甚至模拟测试时替换为内存实现；
只要 User.Query() 方法签名不变，所有调用方代码零修改——这正是迪米特法则的核心价值：降低模块间耦合，保障内部变更的封闭性。
⚠️ 注意事项：
- 嵌入未导出类型（如 struct{ unexportedType }）不会导致 LoD 违反，因其字段/方法无法被外部访问；
- u.Query() 调用是否合规，与该方法是否由嵌入自动提升无关，而取决于调用者是否感知并依赖嵌入关系；
- 迪米特法则不解决 API 不兼容升级（如 sql.Tx.Query 被删除），它保障的是同一接口下实现演进的透明性；
- 不应教条化遵循 LoD：若业务逻辑天然需要操作底层事务（如手动 Tx.Commit()），可提供明确命名的方法（如 u.CommitTransaction()），而非强行隐藏。
总结：嵌入是工具，不是原则。Go 的设计鼓励组合优于继承，而迪米特法则恰是组合思想的工程延伸——用清晰的接口契约代替对内部结构的窥探。善用方法封装，让 User 真正成为用户（User）的抽象，而非 sql.Tx 的别名。
