嵌套模块调用本质是显式分层委托而非层层defer；需依赖抽象接口、入口注入依赖、边界处统一用%w包装错误以保留原始类型，避免重复包装或未导出字段导致静默失败。
嵌套模块调用不是“层层 defer”，而是显式分层委托
Go 没有传统意义的“模块嵌套调用”语法，所谓“嵌套模块调用”实际是开发者对多层函数/方法调用链的误称。真正需要关注的是：如何让跨包、跨层级的调用关系清晰、可测试、不泄露内部实现细节。
常见错误是把 database.Connect() → user.Load() → cache.Get() 这类链式调用硬编码在业务逻辑里，导致单元测试无法 mock、错误上下文丢失、职责边界模糊。
- 每个层级只依赖抽象接口（如
UserRepo），而非具体实现（如postgres.UserRepo） - 调用链入口应接收所有必要依赖，而非在函数体内 new 出来（避免隐藏依赖）
- 避免在中间层重复包装错误——只在边界处（如 handler 或 CLI 入口）用
%w添加上下文
嵌套调用中错误链必须保留原始类型信息
如果 user.Load() 返回 sql.ErrNoRows，而你在 service.GetUser() 里写成 fmt.Errorf("get user failed: %v", err)，那下游就再也无法用 errors.Is(err, sql.ErrNoRows) 判断了。
正确做法是统一用 %w 包装，并确保每层只加一层上下文：
func (s *Service) GetUser(id int) (*User, error) {
u, err := s.repo.FindByID(id)
if err != nil {
return nil, fmt.Errorf("failed to fetch user %d from repo: %w", id, err)
}
return u, nil
}
- 不要连续两次用
%w包装同一个错误（会破坏链长，且无意义） - 底层包（如 repo）应直接返回原始错误，不自行包装
-
errors.As只能解出最内层匹配的错误类型，所以包装层级不宜过深（通常 ≤3 层）
嵌套初始化时避免结构体字段未导出导致的静默失败
当模块 A 初始化模块 B，B 又依赖模块 C，若其中某层结构体字段是小写字母开头（如 config.dbHost string），会导致 JSON 解析、反射赋值、跨包访问全部失效，但编译器不报错——这是最易被忽略的“静默陷阱”。
典型场景：配置加载后传给 service，service 再传给 repository：
type Config struct {
DBHost string `json:"db_host"` // ✅ 导出字段
dbPort int `json:"db_port"` // ❌ 小写，json.Unmarshal 不会设置它
}
- 所有需序列化、反序列化、被其他包访问的字段，首字母必须大写
- 构造函数（如
NewService(cfg Config)）应校验关键字段非零值，而不是等运行时报 nil panic - 不要用匿名结构体传递配置（如
func New(cfg struct{ Host string })），它无法复用、无法扩展、无法测试
深层嵌套调用的性能与可观测性代价常被低估
一个请求经过 handler → service → repo → driver → net.Conn，每层都加日志或 metrics，很容易产生冗余埋点和上下文丢失。
真正有效的做法是：
- 只在入口（
handler）和出口（driver）打完整 trace log，中间层只记录关键决策点（如 “skip cache due to stale flag”） - 用
context.WithValue传递请求级元数据（如 requestID），但别塞太多键值对——建议 ≤3 个 - 避免在每层都调用
time.Now()计算耗时；改用统一的middleware或defer统计入口到出口总耗时
嵌套本身不慢，慢的是没想清楚哪一层该做什么、不该做什么。最麻烦的从来不是调用深度，而是某一层偷偷改了 context、覆盖了 error、或者把 config 当全局变量用了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
