在 Go 语言中，复合字面量是创建结构体实例最直接的方式，但它并不只有一种写法。你可以按照字段声明的顺序逐一填值，也可以显式写出字段名再赋值。两者看似只是风格差异，实际会影响到代码在结构体字段变化时是否还能安全编译、是否会让赋值语义悄悄改变。而当结构体里出现嵌入式字段时，初始化规则又叠加了一层：嵌入类型本身就是字段名，提升字段却不能直接写在字面量里。下面从最基础的初始化形式讲起，再扩展到嵌入字段的构造模式。

结构体初始化的两种基础形式

Go 的复合字面量分为键名初始化和位置初始化。键名初始化写作 FieldName: value，位置初始化则省略字段名，直接按声明顺序列出所有值。比如一个简单的 Config 结构体可以这样初始化：

type Config struct {
    Host string
    Port int
}
// 位置初始化
c1 := Config{"localhost", 8080}
// 键名初始化
c2 := Config{Host: "localhost", Port: 8080}
// 键名可以省略零值字段
c3 := Config{Host: "localhost"}

位置初始化的优点非常明显：代码短，适合字段数量固定且语义稳定的场景，比如标准库里的 image.Point{X: 1, Y: 2} 也可以写成 image.Pt(1, 2)。但它的缺点同样突出：一旦结构体增加或调整字段顺序，所有位置初始化都可能被错误赋值。更危险的是，如果新插入的字段类型与原字段兼容，编译仍然通过，但业务含义已经出错。键名初始化则把字段名和值绑定在一起，结构体增删字段时，旧代码会编译失败或只留下零值字段，问题更容易暴露。

在同一个包内部，这个差异也许可以靠编码规范约束；一旦跨包使用，未导出字段的限制还会进一步影响初始化方式。比如外部包无法在复合字面量中为未导出字段赋值，哪怕使用位置初始化也不行。因此很多库会提供构造函数，而不是让调用方直接拼字面量。理解了这两种基础形式，再看嵌入式字段如何参与初始化，会更清楚组合带来的特殊规则。

嵌入式字段的初始化规则

Go 没有继承，而是通过类型嵌入实现组合。嵌入一个类型时，该类型的名字就是外层结构体的字段名，字段类型就是被嵌入的类型。初始化嵌入字段时，键名必须使用类型名本身，不能使用被嵌入类型内部的字段名。下面是一个值嵌入的例子：

type Logger struct {
    Prefix string
}
type Server struct {
    Logger
    Addr string
}
s := Server{
    Logger: Logger{Prefix: "main"},
    Addr:   ":8080",
}

这里 Logger 既是类型名，也是 Server 的字段名。在 Server 的字面量中，不能直接写 Prefix: "main"，因为 Prefix 是提升字段，不属于 Server 的直接字段。编译器会报错：unknown field Prefix in struct literal of type Server。必须通过嵌入字段完整初始化。这个规则对指针嵌入同样适用：

type Server struct {
    *Logger
    Addr string
}
s := Server{
    Logger: &Logger{Prefix: "main"},
    Addr:   ":8080",
}

指针嵌入在初始化时需要显式给出一个指针值，否则嵌入字段为零值 nil。之后调用提升的方法或访问提升字段时，就会触发空指针。接口嵌入的初始化则是把某个具体实现赋给接口字段，外部通过构造函数或配置项注入：

type Listener interface {
    Listen() error
}
type TCPServer struct {
    Listener
    Addr string
}
s := TCPServer{
    Listener: &TCPListener{Addr: ":8080"},
    Addr:     ":8080",
}

嵌入式字段让外层结构体自动获得内部类型的方法和字段，但初始化时必须回到类型名这一层。这种规则也让构造函数和选项模式有了更多用武之地，因为如果直接暴露结构体字面量，调用方需要知道所有嵌入类型的具体实现和初始化顺序。

常用构造模式：零值、构造函数与函数式选项

最简单的构造模式是零值可用。如果一个结构体在零值状态就能正常工作，那么用户完全不需要初始化，直接声明变量即可。标准库中的 sync.Mutex、bytes.Buffer 都是零值可用的典型。对于含嵌入字段的结构体，只要嵌入的是零值可用的值类型，外层结构体的零值往往也能直接用。例如：

type Counter struct {
    sync.Mutex
    count int
}
var c Counter
c.Lock()
c.count++
c.Unlock()

这里 Counter 的零值里，嵌入的 sync.Mutex 也是零值，可以直接使用。但如果嵌入的是指针或接口，零值就是 nil，不能直接调用提升方法。此时就需要借助构造函数。构造函数通常命名为 NewXxx，返回一个已经完成必要初始化的实例，可能是值也可能是指针。

func NewServer(addr string, logger *Logger) *Server {
    if logger == nil {
        logger = &Logger{Prefix: "default"}
    }
    return &Server{
        Logger: logger,
        Addr:   addr,
    }
}

构造函数能封装默认值、参数校验和嵌入组件的装配逻辑，但它的问题在于参数数量会随着可选配置增多而膨胀。函数式选项模式解决了这个矛盾。它把可选配置封装成一个个函数，构造函数接收不定数量的选项，依次应用到实例上：

type Option func(*Server)
func WithAddr(addr string) Option {
    return func(s *Server) {
        s.Addr = addr
    }
}
func WithLogger(logger *Logger) Option {
    return func(s *Server) {
        s.Logger = logger
    }
}
func NewServer(opts ...Option) *Server {
    s := &Server{
        Logger: &Logger{Prefix: "default"},
        Addr:   ":8080",
    }
    for _, opt := range opts {
        opt(s)
    }
    return s
}
// 调用
s := NewServer(
    WithAddr(":9090"),
    WithLogger(&Logger{Prefix: "api"}),
)

函数式选项的可扩展性最好，新增配置项只增加一个函数，不会破坏已有调用。它也特别适合嵌入式字段较多的结构体，因为调用方不需要自己拼装嵌入类型的字面量。当然，选项模式会引入更多函数和闭包，小型结构体用它反而显得重。实际项目中可以根据字段数量、默认值多少以及是否需要对外隐藏实现细节来选择。

嵌入式字段初始化的典型陷阱

第一个陷阱是跨包使用位置初始化。Go 语言规范没有完全禁止对含未导出字段的结构体使用复合字面量，但如果其他包尝试用位置初始化包含未导出字段的结构体，编译器会直接报错。即便是本包内，位置初始化也会让嵌入字段的位置变得不直观。比如 Server{"main", ":8080", true} 里第三个布尔值究竟对应什么字段，阅读者必须回看结构体定义。这正是 go vet 工具会对未键名字面量发出警告的原因。

第二个陷阱是嵌入指针的 nil 问题。很多人写完构造函数返回一个结构体，但忘记初始化嵌入的指针字段，随后在调用某个由指针类型提升的方法时触发 panic。例如：

type Server struct {
    *Logger
    Addr string
}
func NewServer(addr string) *Server {
    return &Server{Addr: addr}
}
s := NewServer(":8080")
s.Infof("start") // panic: runtime error: invalid memory address or nil pointer dereference

避免这个问题的办法是在构造函数里判断或默认赋值，或者把嵌入字段改成值类型。如果确实需要指针嵌入以保持共享状态，就必须在文档里明确说明，并通过函数式选项等方式强制调用方注入。

第三个陷阱是提升字段冲突。如果两个嵌入类型都定义了同名字段或方法，外层结构体通过选择器访问这个字段时会编译失败，Go 不会自动决定使用哪一个。例如同时嵌入 File 和 Logger，两者都有 Name 字段，那么 s.Name 就存在二义性。此时只能用完整路径 s.File.Name 或 s.Logger.Name 来访问。初始化时也一样，不能在外层字面量里直接写 Name。

最后是序列化与嵌入字段的交互。Go 的 encoding/json 包在处理嵌入字段时会把提升字段平铺到 JSON 输出中，但反序列化时依然遵循类型名映射规则。如果 JSON 中直接出现了嵌入类型内部的字段名，能否正确解析取决于具体实现和标签设置。明白初始化规则和序列化规则之间的差异，可以避免在调试时把两个问题混为一谈。

总体上，Go 结构体初始化看起来简单，一旦叠加嵌入式字段和跨包可见性，就会产生不少细节。优先使用键名初始化，跨包暴露构造函数，必要时引入函数式选项，可以显著降低结构体演化和字段注入带来的维护成本。