构造函数模式必须执行分配、初始化、校验三步，缺一不可；否则含map/slice/指针等字段的结构体实例会在运行时panic，且业务约束字段（如非空ID）需前置校验。
直接用 &T{} 或 new(T) 创建结构体实例，只要字段含 map、slice、*sync.RWMutex 或业务上不允许为空的字段（如 ID string），就大概率在后续调用中 panic。
为什么零值不是安全默认值
Go 的零值是语言层面的“无意义占位符”，不是业务意义上的“可用状态”。比如：
-
map[string]int字段为nil，一写就 panic； -
*http.Client字段为nil，一调用Do()就 panic； -
ID string字段为""，但业务要求非空，后续校验失败或数据库插入报错。
这些都不是编译期能发现的问题，而是运行时突然崩掉。构造函数模式的核心价值，就是把这种“看似合法、实则危险”的实例拦截在创建环节。
构造函数必须做三件事：分配 + 初始化 + 校验
一个合格的 NewXxx 函数不是简单地 &Xxx{} 后返回，它至少要覆盖以下三个动作：
立即学习“go语言免费学习笔记（深入）”；
-
分配：用
&Xxx{}或new(Xxx)都可以，但推荐前者，语义更清晰； -
初始化：对所有引用类型字段显式初始化，例如
m.hm = make(map[string]string)、m.lock = &sync.RWMutex{}； -
校验：对业务约束字段做前置检查，例如
if name == "" { return nil, errors.New("name required") }。
缺一不可。只做前两项，漏掉校验，会把非法输入放行；只做校验不初始化内部字段，依然会在首次使用时 panic。
常见错误：把 New 当成语法糖，结果绕过关键逻辑
很多人写完 NewUser，自己却在别处偷偷用 &User{}，理由是“这个场景很简单”。这是最危险的习惯——一旦结构体加了新字段（比如新增一个 cache map[string]any），旧代码立刻失效。
- 所有对外暴露的结构体，只要字段含引用类型或业务约束，就必须禁止直接字面量初始化；
- 导出结构体字段应设为 unexported（小写），强制走
NewXxx； - 如果已有代码在用
&T{}，不要改调用点，而是把NewXxx实现成唯一入口，并在文档里明确标注 “DO NOT use struct literal”。
真正难的不是写一个 NewXxx，而是让整个团队（包括未来的你）永远不绕过它——这才是构造函数模式落地时最容易被忽略的工程成本。
