Builder 应为值类型但方法用指针接收以支持链式调用且避免状态共享；Build() 必须校验必填字段、格式及业务规则并返回 Error；可选配置宜用函数式选项（Functional Options）提升扩展性与测试灵活性。
为什么直接用 Struct 字面量不够用
当结构体字段多、部分字段有默认值、创建逻辑需要校验或依赖外部状态时，struct{} 字面量会迅速变得难维护。比如 User 需要必填 Name 和 Email，但 Age、Role、CreatedAt 有默认值或需按条件设置——硬编码字段顺序、重复写默认值、漏校验，都是常见问题。
Builder 类型必须是值类型还是指针类型
Builder 本身应定义为**值类型**（如 type UserBuilder struct{...}），但它的方法应全部接收并返回 *UserBuilder。这样能链式调用，又避免意外共享状态。如果 Builder 是指针类型，多个 goroutine 并发调用同一实例会出错；如果是值类型但方法用值接收，则每次调用都复制整个 builder，丢失已设置的字段。
- ✅ 正确：方法签名是
func (b *UserBuilder) Name(name String) *UserBuilder - ❌ 错误：用值接收
func (b UserBuilder) Name(...)→ 字段修改不保留 - ❌ 危险：复用同一个
*UserBuilder实例多次调用Build()→ 后续调用可能污染前次结果
Build() 方法里必须做哪些检查
Build() 不只是组装结构体，更是验证入口。至少检查：必填字段是否为空、字段间约束（如 EndDate 不能早于 StartDate）、业务规则（如邮箱格式）。失败时应返回 error，而不是 panic 或静默忽略。
func (b *UserBuilder) Build() (*User, error) { if b.name == "" { return nil, fmt.Errorf("name is required") } if !strings.Contains(b.email, "@") { return nil, fmt.Errorf("invalid email format") } return &User{ Name: b.name, Email: b.email, Age: b.age, Role: b.role, CreatedAt: b.createdAt, }, nil }如何支持可选配置和扩展性
避免把所有可选字段塞进 Builder 结构体。对复杂配置（如数据库连接参数、http 客户端选项），用函数式选项（Functional Options）组合更灵活。Builder 可提供 WithOption(...Option) 方法，每个 Option 是一个接受 *UserBuilder 的函数。
立即学习“go语言免费学习笔记（深入）”；
- 新增配置不改 Builder 结构体，只加新函数：
WithAdminRole()、WithTrialPeriod(days int) - 测试时可单独传入某几个 option，无需构造完整 builder 实例
- 注意 option 函数内部仍要校验，不能假设调用方已设好前置字段
真正麻烦的不是写 Builder，而是决定哪些字段该暴露、哪些该封在 Build 内部生成（比如 ID 应由 Build() 调用 uuid.New()，而不是让调用方传进来）。