是的，dig.New()创建的容器默认按单例作用域管理生命周期，所有相同类型的构造函数只执行一次，后续获取均为同一实例；若需多实例须显式创建子作用域或使用命名依赖。
dig.New() 创建的容器默认是单例作用域吗？
是的，dig.New() 返回的容器默认只维护一个根作用域（root scope），所有通过 Provide 注册的构造函数，只要类型相同，就只会执行一次——也就是默认按单例（singleton）语义管理生命周期。
这意味着：你注册了两次 func() *DB，第二次 Provide 不会报错，但对应的构造函数不会再次调用；后续所有 Invoke 或 Get 获取到的都是第一次创建的那个实例。
- 如果需要多实例（比如每个 HTTP 请求一个 DB 连接），必须显式创建子作用域（
container.Scope("request")），并在子作用域里Provide - 单例不是靠“加锁”或全局变量实现的，而是靠容器内部的
stagingContainerWriter和scope.graph在解析依赖图时做缓存判断 - 类型相同但想区分多个实例？得用命名依赖：
dig.Name("primary-db")或dig.Name("backup-db")作为ProvideOption
Provide 函数参数顺序会影响依赖解析吗？
不影响。Dig 的依赖解析不看参数声明顺序，而是在 newParamList 阶段通过反射逐个匹配参数类型的可满足性——它只关心“有没有对应类型（+可选 name）的提供者”，不关心谁先谁后。
但实际编码中顺序仍有隐含影响：
立即学习“go语言免费学习笔记（深入）”；
- 如果两个构造函数都返回
*Logger，且都没加dig.Name，后注册的那个会覆盖前一个（因为 map 赋值），此时调用顺序就决定了最终生效的是哪个 - 若存在循环依赖（如
A依赖B，B又依赖A），Dig 在shallowCheckDependencies阶段就会 panic，报错信息类似circular dependency detected: A -> B -> A - 构造函数返回多个值时，Dig 按返回值顺序依次注册，例如
func() (io.Reader, io.Writer)会分别注册io.Reader和io.Writer类型
Invoke 传入函数里用指针接收依赖，为什么有时 panic？
常见原因是类型不匹配或未注册——Dig 在 paramList.BuildList 时严格按参数类型（包括指针/值语义、是否带 interface）查找提供者，哪怕只差一个 * 都会失败。
典型错误场景：
- 注册了
func() Logger（值类型），但Invoke函数写成func(l *Logger)（指针）→ 找不到提供者 - 注册了
func() *sql.DB，却在Invoke中写func(db *database.DB)（包路径不同，即使结构一样也不等价） - 用了
dig.In包装参数，但结构体字段没加导出（小写开头），导致反射无法读取 →panic: cannot set unexported field - 构造函数返回
nil，而 Invoke 函数参数是非空接口（如io.ReadCloser），Dig 不校验 nil，运行时才 panic
为什么在测试中多次调用 container.Invoke 会变慢？
不是 Invoke 变慢，而是每次 Invoke 都会触发一次完整的依赖图遍历和参数构建流程，包括反射读取函数签名、检查依赖满足性、递归解析依赖链——这个过程本身有开销，尤其当依赖树深或类型复杂时。
真正该优化的点是：
- 避免在 hot path（如 HTTP handler 内）反复
Invoke同一类逻辑；应提前Get出服务实例并复用 - 不要在测试里为每个 case 新建
dig.New()+ 大量Provide；可复用容器，或用container.Reset()清空后重用（注意：Reset 不清子作用域） - 大量使用
dig.In/dig.Out结构体时，反射开销上升明显；简单场景直接写参数更轻量 - Dig 的反射缓存（如
constructorNode）在首次解析后生效，但容器本身不自动缓存Invoke的函数签名——每次仍要重新 inspect
最易被忽略的其实是作用域泄漏：子作用域没手动 Close()，其内部对象不会被 GC，长期运行的服务可能出现内存缓慢增长。Dig 不替你管理子作用域生命周期，这点必须手控。
