在 go 中嵌入结构体时，应根据是否需要共享状态、避免拷贝开销或支持运行时动态替换来决定使用值嵌入还是指针嵌入；`log.logger` 等非接口类型两者皆可，但指针嵌入更灵活、更符合常见实践。
Go 的嵌入（embedding）机制是实现组合与方法提升（method promotion）的核心特性。当你将一个类型作为匿名字段嵌入到另一个结构体中时，该类型的方法会自动提升为外层结构体的方法——但这一机制对嵌入类型的形态有明确限制：根据 Go 语言规范，嵌入字段必须是*具名类型 T 或其指针 `T**，且T不能是指针类型（即不支持*T或interface{}）。由于log.Logger` 是一个具体结构体（非接口），因此以下两种写法在语法和语义上均合法：
// ✅ 合法：嵌入值（拷贝语义）
type Job struct {
Command string
log.Logger // 值嵌入
}
// ✅ 合法：嵌入指针（引用语义）
type Job struct {
Command string
*log.Logger // 指针嵌入
}然而，语义差异显著：
值嵌入（log.Logger）：每次创建 Job 实例时，都会完整拷贝一份 Logger 内部状态（如 mu sync.Mutex, out io.Writer, prefix, flag 等）。这不仅带来不必要的内存开销，还可能导致并发安全问题（如多个 Job 实例各自持有独立的 Mutex，无法协同保护共享资源）。
*指针嵌入（`log.Logger）**：所有Job实例可共享同一个Logger实例，方法调用直接作用于原始对象；支持运行时动态重绑定（job.Logger = anotherLogger`），天然适配 Flyweight 模式，大幅提升内存效率与设计灵活性。
例如，考虑如下典型场景：
type Bitmap struct {
data [4][5]bool
}
type Renderer struct {
*Bitmap // 指针嵌入，支持共享底层数据
on, off byte
}
func (r *Renderer) render() {
for _, row := range r.data {
for _, bit := range row {
if bit {
fmt.Print(string(r.on))
} else {
fmt.Print(string(r.off))
}
}
fmt.Println()
}
}
// 共享同一 Bitmap 实例
var pic Bitmap
pic.data[0][0] = true
pic.data[1][1] = true
renderA, renderB := Renderer{on: 'X', off: 'O'}, Renderer{on: '@', off: '.'}
renderA.Bitmap = &pic // 动态绑定
renderB.Bitmap = &pic // 同一底层数组
renderA.render() // 输出含 X/O 的图案
renderB.render() // 输出含 @/. 的同一图案（不同字符映射）✅ 推荐实践：
- 优先使用 *T 指针嵌入，尤其当 T 包含同步原语（如 sync.Mutex）、大字段或需跨实例共享状态时；
- 若 T 是小而无状态的纯数据结构（如 type Point struct{ X, Y int }），且明确需要隔离副本，可考虑值嵌入；
- *永远不要嵌入 `interface{}或T`：它们不携带方法集，违背嵌入的设计初衷（方法提升）；
- 初始化时，配合 NewXXX() 工厂函数（返回 *T）自然契合指针嵌入，无需额外取地址操作。
总之，嵌入不是“语法糖”，而是有明确语义责任的设计选择。选择 *log.Logger 而非 log.Logger，不仅是惯用法，更是对可维护性、内存效率与并发安全的主动承诺。
