Go中初始化结构体应优先使用&T{}，因其语义清晰、支持字段名赋值、自动逃逸上堆且符合标准库风格；避免new(T)和裸字面量，复杂场景必须用NewXXX()构造函数。
直接用 &T{} 初始化结构体指针最稳妥
Go 里初始化结构体，&T{} 是日常开发中应该默认选择的方式——它语义清晰、支持字段名赋值、能触发逃逸分析自动上堆（安全），且和标准库风格一致。
- 别用
new(T)：它只能给零值，不能填字段，写起来还啰嗦，new(User)和&User{}效果一样，但后者一眼就知道是“建个User” - 避免裸字面量
User{"Alice", 25}：字段顺序一变就编译失败，加个未导出字段或调整顺序立刻报错too few values in struct literal - 包外初始化含小写字段的结构体？直接失败——
cannot refer to unexported field，这时候只有工厂函数能救你 - 如果结构体字段含
map、slice、chan或指针，默认零值是nil，不初始化就用会 panic；&T{}不解决这个问题，它只做零值分配，深层初始化还得靠你自己或构造函数
必须用 NewXXX() 构造函数的三种典型场景
当结构体不是“拿来即用”，而是需要校验、默认值、资源预分配或隐藏实现细节时，NewXXX() 不是可选项，是必选项。
-
字段需校验：比如
Name不能为空、Age必须在 0–150 之间，字面量和&T{}都不拦着你传错值，只有NewUser(name, age)能在创建时就抛错 -
含需显式初始化的复合字段：如
map[string]int、*sync.RWMutex、chan int，不make或new就 panic，NewSyncMap()里统一处理最干净 -
封装未导出字段：比如内部有个
cache *big.Cache或logger *zap.Logger，你不希望用户自己填，那就藏在NewService(opts ...Option)里注入
嵌套结构体初始化别硬套字面量，分层写 NewXxx()
像 User{Instances: []Instance{{Configs: []Config{{Replicas: []string{"a","b"}}}}}} 这种写法，不是“写得快”，是“改得痛、读不懂、不敢动”。多层嵌套必须拆开。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每一级结构体都配一个
NewConfig()、NewInstance()、NewUser()，参数精简、字段名明确，比如NewConfig("db-main", "host1", "host2")比Config{"db-main", []string{"host1","host2"}}更易懂 - 切片字段别指望自动扩容——
Configs []Config在&User{}里是nil，不是空切片；NewUser()应该主动初始化为make([]Instance, 0)，避免后续append前还要判空 - 匿名结构体字面量不能复用，每次都要重写类型，比如
struct{X,Y int}{1,2}，这种写法在嵌套里极易失控，一律替换成具名结构体 + 构造函数
方法接收者类型决定你该怎么初始化结构体
初始化方式和方法接收者是强耦合的。如果你定义了 func (u *User) Save()，那你就几乎必须用指针初始化——否则调用会失败。
立即学习“go语言免费学习笔记（深入）”；
-
*T接收者的方法，只能被*T变量调用；T类型变量调用会报错：cannot call pointer method on u - 哪怕你只用
T{}创建值类型，只要后续要调*T方法，就得先取地址：u := User{}; uPtr := &u，不如一步到位写&User{...} - 大结构体（含切片、map、大数组）用值接收者会复制整块内存，性能差；而指针接收者无论怎么初始化，传参都是地址，更轻量
- 接口实现也依赖接收者：如果某个接口方法是
*T接收者，那你必须传*T才能赋值给该接口变量，初始化时没留神，后面对接口赋值就卡住
最容易被忽略的是：字段为 nil map 或 nil slice 的结构体，用 &T{} 初始化完看起来“没问题”，一写就 panic。这不是初始化方式错了，是初始化没做完——该进 NewXXX() 的逻辑，别留在外面补。
