go mod graph 仅展示编译期模块依赖，无法反映云原生环境下服务间真实的运行时调用关系、配置注入或动态注册行为，如 serviceregistry 推送指标、jwt 验证链路、istio sidecar 路由、viper 配置驱动依赖等。
为什么 go mod graph 画不出真实的运行时依赖拓扑
因为 go mod graph 只输出编译期模块依赖，不反映云原生场景下服务间真实的调用关系、配置注入或动态注册行为。它把 github.com/go-kit/kit 和 github.com/prometheus/client_golang 当作平级依赖节点，但实际中前者可能通过 ServiceRegistry 向后者推送指标，这种逻辑依赖不会出现在模块图里。
常见错误现象：go mod graph | dot -Tpng -o deps.png 生成的图看起来很全，但上线后发现关键链路（如 JWT 验证 → 用户中心 → 权限服务）完全没体现。
- 真正要拓扑的是运行时服务实例间的通信路径，不是 Go 源码 import 关系
- 云原生环境里，
service-a调用service-b可能走 Istio Sidecar、gRPC-Web 代理，或通过 Envoy 的 xDS 动态路由，这些都不在go.mod里声明 - 配置驱动型依赖（比如通过
Viper加载 YAML 中的upstream_services列表）也无法被静态分析捕获
怎么从 Prometheus + OpenTelemetry 数据里提取真实调用边
核心思路：不看代码写什么，看 trace span 怎么连。OpenTelemetry SDK 自动注入的 http.url、net.peer.name、rpc.service 等属性，配合 Prometheus 的 http_client_duration_seconds_count{job="service-a"}，就能还原出「谁调了谁」。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确保所有 Go 服务启用 OTLP exporter，指向同一 Collector，且
service.name设置为 Kubernetes 中的Deployment名（而非二进制名） - 在 Collector 配置中开启
spanmetricsprocessor，按span.kind=client和span.kind=server分组聚合，生成traces_to_metrics指标 - 用 PromQL 查询：
count by (job, instance, destination_service) (rate(traces_spanmetrics_latency_count{job=~".+", destination_service!=""}[5m]))—— 这个destination_service就是拓扑里的目标节点
go list -f '{{.Deps}}' ./... 为什么不能替代服务发现数据
它只列出本项目直接 import 的包路径，比如 github.com/redis/go-redis/v9，但无法告诉你这个 Redis 客户端最终连的是 redis-prod:6379 还是 redis-staging:6380，更不会体现连接池复用、分片键路由等运行时决策。
典型坑点：
- 本地开发用
localhost:6379，K8s 里用redis-master.default.svc.cluster.local:6379，go list对这两者毫无感知 - 同一个
redis.Client实例可能被多个 handler 共享，但拓扑图需要体现「auth.Handler → redis」和「order.Handler → redis」两条独立边 - 若用了
github.com/jackc/pgx/v5并启用了 pgxpool，真正的连接目标由PGURL环境变量决定，和源码 import 无直接映射
用 kubectl get endpoints + istioctl proxy-config cluster 补全控制平面信息
Kubernetes Endpoint 对象描述的是 Service 后端 Pod IP 列表，Istio 的 proxy-config cluster 则暴露了 Envoy 实际发起请求的目标域名和端口。二者结合，才能确认「代码里写的 service-b.default.svc.cluster.local」最终落在哪个物理地址上。
操作要点：
- 先执行
kubectl get endpoints service-b -n default -o yaml，提取subsets[].addresses[].ip，这是真实后端 - 再对任一关联 Pod 执行
istioctl proxy-config cluster -n default deploy/service-a --fqdn service-b.default.svc.cluster.local，查看outbound|80||service-b.default.svc.cluster.local对应的hostname和port - 如果 Istio 启用了 TLS 模式
ISTIO_MUTUAL，拓扑图中该边必须标注「mTLS 加密」，否则会误判为明文 HTTP 流量
最常被忽略的是 sidecar 注入状态：未注入 sidecar 的 Pod（比如用 hostNetwork: true 的 DaemonSet）不会出现在 istioctl 输出里，但它仍可能直连其他服务——这部分必须手工补入拓扑。
