Go 错误包裹层数有没有硬性限制？
没有运行时或编译器强加的层数上限。errors.Wrap、fmt.Errorf("...: %w", err) 可以无限嵌套，但不等于应该这么做。
实际限制来自两个地方：栈深度（panic 时 traceback 过长）、内存开销（每层 fmt.Errorf 都分配新 error 实例），以及人眼可读性——查日志时看到 12 层 caused by 基本等于放弃。
常见错误现象：panic: runtime: goroutine stack exceeds 1GB limit（极少见，但嵌套过深 + 循环调用 error 包裹可能触发）；更常见的是日志里一串重复路径，比如 failed to process user: failed to validate input: failed to parse email: failed to parse email: ...（说明逻辑里不小心把同一个 error 多次包裹）。
什么时候该包裹，什么时候该丢弃旧 error？
包裹的核心目的是**补充上下文，且不丢失原始根因**。不是所有 err 都值得传下去。
立即学习“go语言免费学习笔记（深入）”；
该包裹的场景：
- 跨模块边界时（比如从
storage.Read到service.GetUser），加业务语义：fmt.Errorf("failed to get user %d: %w", id, err) - 需要区分错误类型但又不想暴露底层细节时（如把
os.PathError转为自定义ErrUserNotFound，再用%w包住原 error 供调试）
该丢弃/重写 error 的场景：
- 底层错误含敏感信息（如数据库连接串、文件绝对路径），直接包裹会泄露：
fmt.Errorf("internal error: %w", err)不安全，应改用fmt.Errorf("failed to save record") - 错误已明确分类，无需追溯底层（比如 HTTP handler 中，
json.Unmarshal失败统一转成http.StatusBadRequest，没必要保留原始invalid character细节） - 同一函数内多次尝试失败后聚合错误，此时应构造新 error，而非层层包裹（避免
attempt 1 failed: attempt 2 failed: ...）
%w 和 %v 混用导致的调试断层
这是最容易踩的坑：用 %v 或 %s 打印被 %w 包裹的 error，会丢失所有下层信息。只有 %w 或 errors.Unwrap / errors.Is / errors.As 才能穿透。
示例：
err := fmt.Errorf("db query failed: %w", sql.ErrNoRows)
log.Printf("error: %v", err) // 输出 "db query failed: sql: no rows in result set" —— 看似正常，但无法用 errors.Is(err, sql.ErrNoRows) 判断
log.Printf("error: %+v", err) // 输出带堆栈和 cause 链，但依赖 go-errors 或第三方库
log.Printf("error: %w", err) // 编译报错！%w 只能在 fmt.Errorf 内部用，不能用于打印
正确做法是：日志中用 %+v（需导入 golang.org/x/xerrors 或 Go 1.13+ 原生支持）；判断类型用 errors.Is(err, target)；提取底层值用 errors.As(err, &target)。
性能敏感路径下 error 包裹的取舍
在高频调用函数（如网络包解析、循环数据校验）中，每次 fmt.Errorf("...: %w", err) 都涉及内存分配和字符串拼接，比直接返回原 error 慢 3–5 倍（基准测试可验证）。
建议：
- 热路径优先返回原 error，只在出口处（如 API handler、顶层 goroutine）包裹一次，加必要上下文
- 避免在 for 循环内包裹 error：
for _, item := range items { if err := process(item); err != nil { return fmt.Errorf("failed on item %v: %w", item, err) } }→ 改为收集错误或提前 break - 若必须记录详细链路，考虑用结构化日志字段代替多层包裹，例如：
log.With("step", "validate").With("item_id", id).Error(err)
真正难的不是语法怎么写，是每次想 fmt.Errorf("xxx: %w", err) 时，得停半秒问自己：这个 “xxx” 是运维真需要的上下文，还是只是我写代码时的自我安慰？
