builder结构体返回指针而非值以支持链式调用：值接收器复制实例导致字段不累积，指针接收器共享状态使配置持续叠加；build()应返回Error而非panic以保障调用方可控；嵌套配置需通过中间builder或函数式接口确保封装与链式；builder不可并发复用，须每次新建实例。
为什么 Builder 结构体里要返回指针而不是值？
因为链式调用要求每次方法调用后还能继续调用下一个方法，而 go 的值类型传参会复制整个结构体——后续修改只作用于副本，原对象不变，链就断了。
-
func (b Builder) WithName(name String) Builder：返回新副本，前一步的WithName和后一步的WithAge操作的是两个不同实例，字段不会累积 -
func (b *Builder) WithName(name string) *Builder：所有方法操作同一块内存，字段持续叠加，链才成立 - 如果误用值接收器又忘了检查返回值（比如写成
b.WithName("x").WithAge(20)却没把结果赋给b），最终调用Build()时会得到空或默认值
Build() 方法里为什么常做字段校验却很少 panic？
Fluent API 的目标是“错得早、错得清”，但 panic 会让调用方无法恢复；更合理的做法是在 Build() 中集中验证必要字段，缺失时返回 error，由使用者决定是否容忍或兜底。
- 常见错误现象：
Build()直接 panic"name is required"，导致上层逻辑崩溃，尤其在批量构造对象时不可控 - 推荐做法：返回
(T, error)，例如func (b *Builder) Build() (*User, error)，校验失败时返回nil, fmt.Errorf("name is required") - 注意：不要在每个
WithName里校验并 panic——这违背了“延迟验证”原则，用户还没配完就报错，体验差
嵌套结构体怎么保持链式调用不中断？
当 Builder 要配置一个嵌套字段（比如 User.Profile.AvatarURL），直接暴露内层结构会破坏封装；正确做法是提供中间 Builder 或函数式配置入口。
- 错误示范：
b.Profile = &Profile{AvatarURL: "x"}—— 绕过校验、耦合实现、无法链式 - 推荐方式 1（中间 Builder）：
b.WithProfile(&ProfileBuilder{}).WithAvatarURL("x").BuildProfile()，但要注意BuildProfile()必须返回*Builder才能续链 - 推荐方式 2（函数入参）：
b.WithProfile(func(p *Profile) { p.AvatarURL = "x"; p.Size = 48 })，简洁且不新增类型，但需确保p是 builder 内部持有的真实地址 - 容易踩的坑：用函数式配置时，如果 Profile 是值类型字段（
profile Profile），那传进来的p修改的是副本，必须改成指针字段（profile *Profile）
并发场景下 *Builder 能不能复用？
不能。Builder 本质是可变状态的临时容器，没有同步保护，多个 goroutine 同时调用它的方法会导致字段覆盖、竞态甚至 panic。
立即学习“go语言免费学习笔记（深入）”；
- 典型错误：全局声明一个
var userBuilder = NewUserBuilder()，然后在 http handler 里反复userBuilder.WithName(...).WithAge(...).Build() - 正确姿势：每次需要构建对象时都新建 Builder 实例，即
NewUserBuilder().WithName(...).WithAge(...).Build() - 性能影响其实极小——Builder 通常只有几个指针字段，分配开销可忽略；比起加 mutex 或 sync.Pool 带来的复杂度和潜在 bug，每次都 new 更安全、更符合 Go 的惯用法
链式调用看着顺滑，但每一步返回值类型、校验时机、嵌套配置方式、并发安全性，四个点只要一个没对齐，就容易产出“看似能跑、实际漏字段”或者“单测通过、线上偶发 panic”的 Builder。写的时候多问一句“这个返回值接下来会被谁用、会不会被丢弃”，比堆语法糖管用。