runtime.Caller 是日志链路追踪的起点，因其轻量、稳定且无需第三方依赖，能主动抓取调用位置以还原真实流转路径；需合理设置层级（如Caller(2)）、清洗路径、避免滥用Callers，并与context传traceID分工协作。
为什么 runtime.Caller 是日志链路追踪的起点
Go 没有内置的“调用栈上下文传播”机制，想在日志里看到「谁调用了谁」，必须主动抓取调用位置。直接用 log.Printf 打印固定字符串，根本无法还原模块间的真实流转路径。runtime.Caller 是唯一轻量、稳定、标准库支持的方式——它不依赖第三方、不侵入业务逻辑、也不触发 panic。
常见错误是只调用一次 runtime.Caller(1)，结果只拿到当前函数名，漏掉了上游调用者。实际要构建链路，至少得从当前帧往上捞 2–4 层（取决于是否经过 wrapper 函数），并过滤掉标准库和日志封装层。
- 推荐起始层级用
runtime.Caller(2)：跳过日志封装函数本身和它的直接调用者 - 用
filepath.Base和strings.TrimSuffix清洗文件路径，避免输出冗长绝对路径（如/home/user/go/src/mymodule/handler.go→handler.go） - 不要硬编码层数，封装成可配置的
depth参数，默认取 3，调试时临时调高
如何用 log.Logger + io.MultiWriter 实现链路日志自动注入
手动在每个 log.Print 前拼接 runtime.Caller 结果，既重复又易错。更可靠的做法是替换底层 io.Writer，让每次写日志都自动前置调用信息。
关键不是改 log.Printf，而是控制日志输出的源头。用 io.MultiWriter 把原始 writer 和一个带调用链提取的 wrapper 组合起来，就能零侵入地增强所有日志。
立即学习“go语言免费学习笔记（深入）”；
- 封装一个
callerWriter类型，实现io.Writer接口，在Write(p []byte)中先调用runtime.Caller(2)获取文件/行号，再拼接p - 避免在
Write里做耗时操作（比如正则匹配或多次filepath.Abs），否则会拖慢所有日志输出 - 注意：如果日志已含时间戳或 level 前缀（如
[INFO]），要在拼接前剥离首行前缀，否则调用信息会被挤到第二行
context.Context 不能直接存调用栈，但可以存 trace ID + 显式传参
有人试图把 runtime.Caller 结果塞进 context.WithValue，这是典型误用。调用栈是瞬时快照，不是可传递的状态；且 context 设计目标是跨 goroutine 传递请求范围的元数据（如用户 ID、超时），不是用于记录执行路径。
真正需要链路关联的场景（比如 HTTP 请求贯穿 handler → service → dao），应该用 context 传 traceID，再配合各层日志手动注入当前调用点——二者分工明确：context 负责横向关联，runtime.Caller 负责纵向定位。
- HTTP middleware 中生成
traceID并写入 context，后续所有日志都带上这个 ID - 每个关键函数入口处调用
getCallerInfo()（封装好的runtime.Caller提取逻辑），拼进日志字符串 - 避免在循环体或高频路径（如数据库 scan 回调）中反复调用
runtime.Caller，CPU 开销明显上升
生产环境慎用 runtime.Callers 获取完整栈，优先用分层采样
runtime.Callers 能拿到整个栈帧，看起来很完美，但它分配的 slice 大小与栈深度正相关，GC 压力不可忽视。压测时发现日志模块 CPU 占比飙升，往往就是这里出了问题。
真实服务不需要每条日志都打印 20 层调用。按场景分级更实用：debug 日志全栈，error 日志取前 5 层，info 日志只取当前 + 上一层。
- 定义常量
LogCallDepthDebug = 15、LogCallDepthError = 5、LogCallDepthInfo = 2 - error 日志强制包含
runtime.Caller(2)和runtime.Caller(3)，确保能定位到业务入口函数 - 对性能敏感的服务（如网关、实时计算），禁用全栈，只保留
funcName:line格式，不解析文件路径
调用链不是越深越好，而是要刚好卡在能快速区分问题模块的位置。多一层可能增加 5% 的日志延迟，少一层可能让你多花 20 分钟翻代码。
