静态分析不可信，因go mod graph和代码解析仅反映编译期声明依赖，无法捕获受环境变量、配置文件、feature flag等控制的运行时真实调用链，且会混入test-only依赖导致虚假边。
服务依赖拓扑图不能靠静态扫描生成，必须由 Go 服务在运行期自主上报真实调用行为——否则你看到的只是 import 列表，不是实际流量路径。
为什么 go mod graph 和代码解析完全不可信
静态分析只能看到编译期声明的依赖，而真实调用链受配置、开关、环境变量、运行时参数影响极大。比如一个 mysql.Open 调用可能只在 env == "prod" 时触发；Kafka topic 订阅关系写在 config.yaml 里，根本不会出现在 AST 中；gRPC client 初始化可能被 feature flag 控制。更严重的是，go list -f '{{.Deps}}' 会把 test-only 的依赖、mock 包、工具包全算进去，导致拓扑图出现大量虚假边。
HTTP/gRPC 调用必须用 interceptor 埋点，不能靠日志或中间件拼接
常见错误是写个 HTTP middleware，在 handler 里用 log.Printf 打印 "%s → %s"，结果字段无法结构化解析、时间戳不准、丢失协议/端口信息，且阻塞主流程。正确做法是：
- HTTP 客户端：用自定义
http.RoundTripper包裹默认 transport，在RoundTrip入口提取req.URL.Host或X-Service-Targetheader，构造DependencyEdge并异步写入本地 buffer - gRPC 客户端：实现
grpc.UnaryClientInterceptor，从method字符串（如/user.UserService/GetProfile）提取服务名，避免依赖不稳定的grpc.peer.address - HTTP 服务端：在 middleware 创建 span 后立刻调用
span.SetAttributes(attribute.String("http.route", r.URL.Path))，不靠反射或 URL 解析
上报数据必须含明确语义标签，不能只传 service name
只上报 source_service 和 target_service 会导致拓扑图失去分层能力，MySQL 和 Kafka 都显示成“服务”，掩盖真实架构意图。关键字段必须包含：
-
Protocol：固定为"http"、"grpc"、"kafka"、"mysql"等标准值，禁止用"tcp"或"network"这类泛化词 -
Environment：来自启动参数或环境变量（如os.Getenv("ENV")），不能硬编码 -
Port：HTTP 用req.URL.Port()，gRPC 从 dial target 解析，Kafka 从 config 取，MySQL 从 DSN 提取 -
Timestamp：用time.Now().UnixMilli()，别用纳秒级时间戳——前端渲染和聚合都容易溢出
别自己写中心存储，优先复用 OpenTelemetry Collector + Prometheus Pushgateway
独立开发拓扑中心服务成本高、收敛慢、易成为单点瓶颈。生产环境推荐组合：
- 采集端：每个 Go 服务内嵌
topo.Collectorgoroutine，每 30 秒聚合本地内存中的DependencyEdge切片，去重后 POST 到http://otel-collector:4318/v1/metrics - 转换层：OTel Collector 配置
prometheusremotewriteexporter，将边数据转为dependency_edge_count{source="a", target="b", protocol="http", env="prod"}这类指标 - 存储与查询：Pushgateway 接收并保留最近 2 小时数据，Grafana 用 PromQL 查询
sum by (source, target, protocol) (dependency_edge_count)即可驱动拓扑图节点边生成
真正难的不是采集，而是让所有团队对 peer.service 命名达成一致——比如订单服务调用用户服务，必须统一填 "user-svc" 而不是 "user"、"users" 或 "user-service"，否则拓扑图里会出现多个孤立节点指向同一真实服务。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
