用 *Config 而不是 Config 传参是因为 Go 值传递会复制结构体，而指针轻量且支持 nil 判空实现可选配置；需先判空再解引用，避免 panic，并按字段单独判断是否覆盖，默认值优先。
为什么用 *Config 而不是 Config 传参
因为 Go 函数参数是值传递，传 Config 会复制整个结构体；而传 *Config 只传地址，既轻量又能原地修改字段。更重要的是——它天然支持“未设置即忽略”：调用方传 nil，函数里判空跳过初始化，这就是可选配置的底层逻辑。
常见错误是把 *Config 当成“必须非空”，结果一上来就解引用导致 panic：panic: runtime error: invalid memory address or nil pointer dereference。
- 只在明确需要读写字段时才解引用，比如
cfg.Timeout - 所有字段访问前先做
if cfg != nil判断 - 如果只是想“合并默认值”，更安全的做法是用
config := defaultConfig()+if cfg != nil { merge(config, cfg) }
func NewClient(cfg *Config) 的典型实现模式
这是最常被搜索的签名形式。关键不在指针本身，而在如何安全、清晰地处理 nil 和部分覆盖。
使用场景：SDK 初始化、HTTP 客户端构造、数据库连接池配置等需要大量可选参数的地方。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要在函数开头就
cfg.Timeout—— 先检查if cfg == nil - 为每个字段单独判断是否设置，比如
if cfg != nil && cfg.Timeout > 0，避免用零值覆盖默认值（Timeout=0可能是有意设为无超时） - 推荐用结构体字面量构造默认实例，再按需覆盖：
conf := Config{Timeout: 30 * time.Second, Retries: 3} if cfg != nil { if cfg.Timeout > 0 { conf.Timeout = cfg.Timeout } if cfg.Retries >= 0 { conf.Retries = cfg.Retries } }
和 func NewClient(opts ...Option) 的区别在哪
*Config 是扁平、集中、强结构的可选配置；...Option 是灵活、可扩展、易组合的函数式配置。两者不互斥，但目标不同。
容易踩的坑是强行把 Option 套壳成 *Config，比如写一个 WithConfig(*Config)，反而让调用方困惑：到底该传 *Config 还是用 WithXxx？
- 如果你的配置项稳定、数量适中（*Config 更直观、IDE 支持好、文档易生成
- 如果未来要高频新增配置（如加 tracing、metrics、proxy 支持），
Option更易维护，也避免每次改Config结构体引发兼容问题 - 性能上没差别，都是指针传参；但
Option多一次函数调用开销，不过可忽略
嵌套结构体里的 *Config 字段怎么初始化
当 Config 本身含指针字段（比如 Logger *log.Logger），直接传 &Config{} 不等于“全默认”，而是把所有指针字段设为 nil —— 这很可能不是你想要的。
典型错误现象：日志不输出、TLS 配置失效、上下文取消未生效，查半天发现是嵌套字段没初始化。
- 要么在
defaultConfig()函数里显式初始化所有指针字段：Logger: log.Default() - 要么要求调用方自己保证嵌套结构完整，文档里写清楚哪些字段不可为
nil - 避免在
Config里混用值类型和指针类型字段，比如Timeout time.Duration和Logger *log.Logger并存，会让“是否设置”的判断逻辑不一致
实际项目里最麻烦的不是怎么写 *Config，而是团队对“零值是否有效”没有共识。比如 RetryDelay time.Duration 设为 0，是“不重试”还是“立即重试”？这种歧义必须靠文档或类型约束（如自定义类型 + 方法校验）来堵住，光靠指针解决不了。
