Go中几乎都用NewXXX而非MakeXXX或CreateXXX，因NewXXX专指返回新分配指针的轻量构造函数，MakeXXX仅用于内置类型初始化，CreateXXX易引发语义混淆。
为什么 Go 里几乎都用 NewXXX 而不是 MakeXXX 或 CreateXXX
因为 Go 标准库和社区约定：只要函数返回新分配的（heap 上的）指针类型实例，就统一用 NewXXX；MakeXXX 专用于内置类型（map、slice、chan）的初始化，它不分配结构体；CreateXXX 则容易让人误以为会做复杂初始化或副作用（比如注册、启动 goroutine），实际工厂函数应保持轻量。
常见错误现象：CreateUser() 返回 *User，但调用方下意识认为它可能“创建数据库记录”，结果发现只是内存分配——造成语义混淆。
-
NewXXX函数必须返回指针（*T），且内部通常只做字段零值填充或简单赋值 - 如果构造逻辑涉及 I/O、锁、goroutine 启动，不应塞进
NewXXX，而应拆出显式Start()或Init()方法 - 标准库中
net/http.NewRequest是个例外（返回值非指针），但它属于历史兼容设计，新代码别学
NewXXX 函数要不要接收参数？怎么设计参数顺序
要，但只收「构造对象必需的、不可推导的」字段。比如 User 必须有 name 才能存在，那就收；createdAt 可由函数内 time.Now() 填充，就不该暴露给调用方。
参数顺序按「必要性 + 不变性」排列：必填在前，可选在后；基础类型（string、int）优先于结构体或接口。
立即学习“go语言免费学习笔记（深入）”；
- 错误示范：
NewUser(cfg Config, name string)——Config如果只是用来设默认值，说明职责过重 - 推荐写法：
NewUser(name string, opts ...UserOption)，把可选配置抽成函数式选项（WithAge(25)），避免参数爆炸 - 如果只有 1–2 个必填参数，直接列出来；超过 3 个，考虑用选项模式，否则调用时易错位（尤其都是
string类型）
什么时候不该写 NewXXX？替代方案是什么
当类型本身是值类型、且零值可用时，压根不需要工厂函数。比如 type Point struct{ X, Y float64 }，直接写 Point{X: 1, Y: 2} 更清晰；强行加 NewPoint(x, y) 反而增加认知负担。
常见错误场景：为每个结构体无脑配 NewXXX，结果发现 80% 的调用方其实只用零值，或者只改一两个字段。
- 值类型 + 零值有意义 → 直接字面量初始化，不写工厂
- 需要共享状态或全局单例 → 用包级变量 + 初始化函数（如
func init() { defaultClient = NewHTTPClient() }），而不是每次调用NewXXX - 构造过程需校验（如邮箱格式、端口范围）→ 把校验逻辑放进
NewXXX，失败时返回(*T, error)；别让调用方自己检查字段再决定是否创建
并发安全吗？NewXXX 内部能加锁或访问全局变量吗
不能。工厂函数必须是纯的（pure）：输入相同，输出确定；不读写全局状态，不依赖时间/随机数/环境变量；不启动 goroutine；不加锁。
一旦 NewXXX 里出现 mu.Lock() 或 sync.Once，它就不再是“创建实例”，而是“获取/初始化共享资源”——这应该叫 GetXXX 或 DefaultXXX。
- 典型坑：
NewLogger()里偷偷复用一个全局io.Writer并加锁，导致并发调用时性能骤降，且行为难以测试 - 正确做法：锁、缓存、连接池等交给具体方法（如
l.Log()），工厂只负责组装结构体字段 - 如果真需要延迟初始化（比如 lazy HTTP client），用
sync.Once+ 字段指针封装，但函数名得改成DefaultClient()，和NewXXX划清界限
最常被忽略的一点：很多人把 NewXXX 当作“初始化入口”，往里塞日志、指标上报、配置加载——这些操作应该发生在对象的生命周期管理阶段（比如 Start() 方法），而不是诞生那一刻。工厂函数的边界，就是内存分配和字段赋值。
