最稳妥路径是用 context.context + 自定义 log.logger 封装：入口注入 trace_id 到 ctx，封装 withcontext 方法从中提取并写入日志字段，下游函数仅传 ctx 即可自动携带调用链 id。
Go日志中如何让嵌套函数自动携带调用链ID
直接给结论：不用手动传参，用 context.Context + 自定义 log.Logger 封装是最稳妥的路径。Go 标准库不自带“上下文感知日志”，但 context 本身支持键值传递，只要在入口处注入 trace_id，后续所有日志调用都能从 ctx 中取出来。
常见错误是每个函数都加一个 traceID string 参数，既破坏签名又容易漏传；或者用全局变量/ goroutine local storage（如 goroutineid 包），但 Go 1.22+ 的 runtime/debug.ReadBuildInfo() 不支持稳定 goroutine ID，且无法跨协程传播。
- 入口处生成唯一
trace_id（例如用uuid.New().String()），塞进context.WithValue(ctx, key, traceID) - 封装一个
WithContext(ctx context.Context) *Logger方法，内部从ctx提取trace_id并写入日志字段 - 所有下游函数只接收
ctx，不额外传traceID—— 日志模块自己查
为什么 zap.Logger.WithOptions(zap.AddCallerSkip(1)) 不能解决嵌套日志行号错位
zap.AddCallerSkip(1) 只跳过一层调用栈，而多级嵌套时，真正想定位的是业务代码位置（比如 service/user.go:42），不是日志封装层的 logger.go:88。跳过层数固定，但嵌套深度会变，硬编码 skip 值必然失效。
正确做法是让日志实例“记住”它被创建时的调用点，而不是每次写日志时动态算。Zap 支持 zap.AddCaller() + 自定义 zap.Core，但更轻量的方式是：在封装的 NewLogger() 初始化时，用 runtime.Caller(1) 捕获一次调用位置，存为 logger 实例字段，再通过 zap.Fields() 固定注入。
- 避免在
Info()等方法里反复调用runtime.Caller()，性能损耗明显 - 如果必须支持运行时动态 skip（比如中间件透传），改用
zap.WrapCore()替换core，在Write()阶段重新计算 caller -
zap.AddCallerSkip(n)的n是相对于logger.Info()调用点的偏移，不是相对于文件开头
多个 goroutine 共享同一个 logger 实例是否线程安全
是的，zap.Logger 和 log/slog.Logger 都是并发安全的，但前提是别动它的内部状态。常见踩坑点是：在 handler 或 hook 里修改 logger 字段（比如 logger = logger.With(...) 后没返回新实例，而是试图复用原实例），导致不同 goroutine 写日志时字段互相覆盖。
关键原则：所有 WithXXX 方法（如 With、WithGroup）都返回新 logger，原实例不变。多级嵌套场景下，每个子任务应基于父 ctx 的 logger 衍生出自己的带 trace_id 的实例，而不是共用一个 mutable logger。
- 错误写法：
logger.With("trace_id", id); logger.Info("msg")——With返回值被丢弃 - 正确写法：
logger := logger.With("trace_id", id); logger.Info("msg") - 若用
slog，注意slog.With()返回新slog.Logger，但slog.Handler实现若缓存了字段，需确认其是否支持并发写入
log/slog 在 Go 1.21+ 中如何与 trace_id 关联而不依赖第三方包
slog 原生支持 Handler 层面的上下文注入，不需要 uber-go/zap 或 go-kit/log。核心是实现一个自定义 slog.Handler，在 Handle() 方法里从 r.Context() 提取 trace_id，再合并到 attrs 中输出。
注意：标准 slog.NewJSONHandler 或 slog.NewTextHandler 不读取 context，必须自己 wrap。而且 slog.Record 本身不携带 context，所以 Handler.Handle() 的第一个参数 r 是 slog.Record，没有 ctx 字段 —— 这意味着你得在 Handler 初始化时绑定一个默认 ctx，或要求调用方显式传入（不现实）。实际可行方案是：把 trace_id 当作 slog.Group 的一部分，在入口处用 slog.With("trace_id", id) 创建顶层 logger，后续所有 .Info() 都继承该字段。
- 不要试图在
Handler里调用context.FromGoRoutine()—— Go 没有 goroutine-local context -
slog.With()是 cheap 的，它只是把字段挂到 logger 实例上，不触发序列化 - 如果用
slog.WithGroup()嵌套，确保 group 名不冲突（比如都叫"req"），否则字段会被覆盖
trace_id 而不是混用 traceId、TraceID、x-trace-id），否则下游做聚合分析时会漏数据。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
