Go服务SkyWalking Agent不加载的根本原因是agent未在main()首行初始化或环境变量缺失；需显式调用go2sky.NewTracer()并设全局tracer，配置SW_AGENT_NAME与SW_AGENT_BACKEND_SERVICES，HTTP透传须用sw8协议，gin需用go2sky-gin适配器归一化路由，goroutine须显式传递带span的ctx。
Go服务启动时SkyWalking Agent不加载
根本原因通常是 skywalking-go 的 agent 没有在 main() 最早阶段初始化，或环境变量配置缺失。Go 的 SkyWalking 官方 SDK（apache/skywalking-go）不支持 Java 那种 JVM Agent 方式，必须显式调用 go2sky.NewTracer() 并注入全局 tracer。
常见错误现象：no trace data reported、UI 中服务名显示为 unknown、HTTP 接口无 span 上报。
- 确保在
main()函数第一行就初始化 tracer，例如：tracer, _ := go2sky.NewTracer("my-go-service")<br>go2sky.SetGlobalTracer(tracer) - 必须设置环境变量
SW_AGENT_NAME和SW_AGENT_BACKEND_SERVICES，否则 tracer 构建失败但静默忽略（不会 panic） - 若使用
gin或echo，需手动挂载中间件；net/http默认支持，但需用http.DefaultServeMux或显式传入带 trace 的 handler
HTTP请求链路中断，下游服务收不到父span
本质是 HTTP header 透传未对齐 SkyWalking 的传播协议（B3 / SW8）。Go SDK 默认使用 sw8 格式，但很多旧版网关或自定义 client 会丢弃或覆盖 sw8 头字段。
典型表现：上游生成了 traceId，下游日志里 trace_id 是空的，或新生成独立 trace。
立即学习“go语言免费学习笔记（深入）”；
- 检查 client 请求是否调用
go2sky.CreateSpan()并显式注入：ctx = go2sky.WithSpan(ctx, span)<br>req = req.WithContext(ctx)<br>carrier := &go2sky.Carrier{}<br>span.Inject(context.Background(), carrier)<br>for k, v := range carrier.Headers {<br> req.Header.Set(k, v)<br>} - 若用
resty或http.Client，不能直接复用原 request；必须从 span 提取 carrier 后重新 set header - 确认下游服务也使用
sw8解析（不是 B3），否则 header 名（如sw8vstraceparent）不匹配会导致解析失败
gin框架集成后路由span名称全是“/”
这是因为 gin 默认的中间件没提取路由模板，而是记录了原始 path（如 /user/123），而 SkyWalking 要求将动态路径归一化为 pattern（如 /user/{id}）才能聚合统计。
不修复会导致 UI 中同一接口分散成上百个不同 span 名，无法看 QPS、慢调用趋势。
- 必须使用
go2sky-gin适配器（非官方但广泛验证），而非手写中间件：import "github.com/SkyAPM/go2sky-plugins/gin/v5"<br>r.Use(gin2sky.Middleware(exporter))
- 确保 gin 启动前已注册路由（
r.GET("/user/:id", ...)），否则中间件无法获取路由树信息 - 若用 gorilla/mux 或 chi，需对应找
go2sky-mux或自行实现Router.GetRouteName()逻辑
事务跨goroutine丢失上下文
Go 的 context 仅在线程内传递，goroutine 启动时若未显式传入带 span 的 ctx，新 goroutine 就会创建孤立 span，导致分布式事务断裂。
最常发生在异步发消息（Kafka/RabbitMQ）、定时任务、数据库事务 commit 后回调等场景。
- 永远不要在 goroutine 内直接调用
go func() { ... }()，而要用：ctx := go2sky.ContextWithSpan(context.Background(), span)<br>go func(ctx context.Context) {<br> // 在此处继续 trace<br>}(ctx) - 数据库操作若用
sqlx或gorm，需确认其 context-aware 方法（如GetContext()）被调用；否则 SQL span 不会关联到父 trace - log 库（如
zap）需配合go2sky-zaphook，否则日志里看不到 traceId，排查时无法串联
真正难的不是埋点，是保证每个 goroutine、每条消息、每次 DB 查询都带着正确的 context —— 这需要团队对 trace 生命周期有统一认知，而不是靠 SDK 自动兜底。
