WithXXX函数不该做参数校验，校验应推迟到构建完成后的Validate()方法中统一执行；默认值只写在选项函数内，结构体字段保持零值；必填字段须在构建末尾显式检查或改用构造函数参数强制传入。
Go 选项模式里 WithXXX 函数该不该做参数校验
不该在选项函数内部做严格校验，校验应推迟到构建完成、真正使用前。否则会掩盖调用方的误用时机——比如传了非法值但没被立刻发现，等到服务运行半小时后才 panic，排查成本陡增。
-
WithTimeout接收负数time.Duration是合法的（表示“不超时”），强行拒绝反而破坏语义 - 若需约束值域（如重试次数不能为负），应在最终结构体的
Validate()方法里统一检查，而非分散在每个WithXXX - 选项函数本质是“收集配置”，不是“执行逻辑”，过早校验违背单一职责
默认值该写死在结构体字段声明，还是藏在选项函数里
默认值必须只出现在一个地方：选项函数内部。结构体字段声明一律用零值（0、nil、""），否则会和选项模式产生冲突。
- 如果
type Client struct { Timeout time.Duration }写成Timeout: time.Second，再调用WithTimeout(5 * time.Second)就可能被覆盖两次，行为不可控 - 所有默认值由
WithXXX显式提供，例如func WithTimeout(d time.Duration) Option { return func(c *Client) { c.timeout = d } }，这样能保证“未调用即无默认” - 零值字段 + 选项函数默认参数，才是可预测的组合；混用字段初始化和选项函数，会让代码读起来像猜谜
多个 WithXXX 调用顺序是否影响结果
会影响，尤其是涉及覆盖型字段（如 timeout、host）时，后调用的选项永远生效。但对叠加型字段（如切片类的 middleware），顺序决定执行先后。
- 不要依赖“先设置 host 再设置 port 就能拼接 URL”这类隐式顺序逻辑，应合并为
WithURL或显式校验 - 如果两个选项修改同一字段（如
WithTimeout和WithDeadline），后者必然覆盖前者，且不会报错——这是设计使然，不是 bug - 想强制互斥？加个
validateOptions()在构建末尾检查冲突，而不是靠调用顺序兜底
为什么生产环境要禁用未设默认值的必填字段
因为不设默认值的字段，在选项模式下极易变成“静默空值”。比如 apiURL 没配，结构体里是空字符串，HTTP client 发请求时才报 parse "" 错误，此时服务已启动成功。
立即学习“go语言免费学习笔记（深入）”；
- 必填字段必须在最终构建阶段显式检查，例如
if c.apiURL == "" { return errors.New("apiURL is required") } - 不要指望单元测试覆盖所有漏配场景——人在写初始化代码时容易跳过某个
WithAPIURL，而编译器不报错 - 更稳妥的做法：把必填字段从结构体移出，改为构造函数参数（
NewClient(apiURL string, opts ...Option)），让 Go 类型系统兜底
最麻烦的不是写错选项，而是所有选项都写了，但某个字段因命名相似（比如 WithBaseURL vs WithAPIURL）被漏掉，还跑得通——这种问题在线上才会暴露，且难以复现。
