因为make()仅支持slice、map、chan三种内置引用类型，对结构体调用会在语法分析阶段报“cannot make type XXX”；结构体是值类型，需用字面量{}、new()或New函数显式初始化，且内部引用字段须单独make。
为什么不能直接用 make() 初始化结构体
因为 make() 只支持 slice、map 和 channel 三种引用类型，对自定义 struct 调用会直接报编译错误：cannot make type XXX。结构体是值类型，它的内存布局和初始化逻辑由字段决定，必须显式构造。
常见误用场景包括：试图用 make(MyStruct) 初始化含 map[string]int 字段的结构体，结果编译失败；或侥幸绕过编译（比如用 new(MyStruct)）却忽略内部 map 或 slice 仍是 nil，后续写入 panic。
-
new(T)只做零值分配，不初始化内部引用字段 -
&T{}同样返回零值结构体，map/slice字段仍为nil - 真正安全的初始化必须显式调用
make()对每个引用字段单独处理
NewXxx() 函数该返回指针还是值
绝大多数情况下返回 *Xxx —— 因为结构体可能较大，避免拷贝开销；更重要的是，只有指针能保证后续方法（尤其是修改字段的方法）作用于同一实例。若返回值类型，SetXXX() 类方法只能修改副本，调用方完全感知不到。
例外是极小、只读、无引用字段的结构体（如 type Point struct{ X, Y int }），可返回值类型提升缓存友好性，但需明确文档说明“不可变”语义。
- 含
map、slice、channel或需要方法修改状态的结构体，必须返回指针 - 返回值类型时，所有字段应为基本类型且无 setter 方法，否则易引发误用
- 函数名必须以
New开头（如NewUser()），这是 Go 社区强约定，影响工具链识别（如go vet）
嵌套结构体如何避免初始化爆炸
当结构体 A 包含 B，B 包含 C，直接用字面量写 &A{B: &B{C: &C{...}}} 会导致括号嵌套难读、字段顺序敏感、默认值分散难维护。正确做法是为每一层定义独立的 NewXxx() 函数，并在上层构造函数中组合调用。
例如 User → Instance → Config，NewUser() 内部应调用 NewInstance() 和 NewConfig()，而不是手动 new 每一层。这样每层职责清晰，修改某层默认值只需改对应函数，不影响其他层级。
- 禁止跨层传参（如
NewUser(instanceName, configName)），应分层解耦 - 允许构造函数接收可选参数（如用结构体选项模式），但核心必填字段必须作为函数参数显式声明
- 切片字段优先用
make([]T, 0, cap)预分配容量，避免多次扩容
初始化时最容易被忽略的 nil 安全点
最隐蔽的问题不是 map 或 slice 字段没 make，而是嵌套结构体指针字段未初始化就解引用。例如 type A struct{ B *B }，若 NewA() 返回的 A.B 是 nil，而下游代码直接调用 a.B.DoSomething() 就 panic —— 这种错误不会在编译期暴露，运行时才炸。
解决方案只有两条铁律：要么让嵌套字段成为非指针（如 B B，靠 NewB() 构造并内联初始化）；要么在 NewA() 中强制初始化该指针字段（a.B = NewB()），绝不留 nil 给调用方。
- 所有导出的指针字段，只要业务逻辑要求其非 nil，就必须在
NewXxx()中完成初始化 - 若某字段确实允许为 nil，应在字段注释中明确写出 “// B may be nil”，并确保所有使用方做
if b != nil检查 - 用
go vet的nilness检查器可捕获部分此类问题，但不能替代设计阶段的明确约定
