依赖拓扑必须运行时采集，因真实调用目标由配置、环境变量或feature flag动态决定，静态分析无法反映实际服务间调用关系；有效边仅产生于业务代码执行出向调用时，需通过interceptor埋点并上报含Protocol、Port、Environment、Timestamp等语义字段的DependencyEdge结构体，由服务自身异步上报并配合心跳机制清理过期边。
依赖拓扑必须运行时采集，不能靠 go mod graph
静态分析工具看到的只是 import 和 module 依赖，比如 myapp → github.com/sirupsen/logrus，和“订单服务调用用户服务”毫无关系。真实调用目标由配置、环境变量或 feature flag 决定：HTTP 请求发往哪个域名、gRPC dial 的 target 是什么、Kafka 消费哪个 topic —— 这些全在运行期才确定。
常见错误包括：
- 把
testify这类 test-only 依赖当成真实服务边 - 把
golang.org/x/net这种底层网络库渲染进图，制造噪音节点 - 仅因代码里 import 了
github.com/segmentio/kafka-go就画出一条 Kafka 边，但实际根本没初始化 consumer
真正有效的边，只产生于业务代码执行出向调用的那一刻 —— 「调用即发现」。
HTTP/gRPC/Kafka 调用必须用 interceptor 埋点，不是日志拼接
在 HTTP handler 里写 log.Printf("%s → %s", svc, req.Host) 看似简单，但字段无法结构化解析、时间戳不准、丢失协议/端口、且阻塞主流程。正确路径是拦截客户端出口：
立即学习“go语言免费学习笔记（深入）”；
- HTTP 客户端：用自定义
http.RoundTripper包裹默认 transport，在RoundTrip入口提取req.URL.Host或X-Service-Targetheader - gRPC 客户端：实现
grpc.UnaryClientInterceptor，从method字符串（如"/user.UserService/GetProfile"）解析服务名，比grpc.peer.address更可靠 - Kafka 消费者：在
consumer.Consume启动时，按约定映射 topic 到上游服务（如"order.created" → "order"），写入边记录
避免在中间件里动态解析 Referer 或 X-Forwarded-For 推断上游——这违反服务自治原则，且网关透传头可能被篡改或缺失。
上报数据必须带语义字段，不能只传 service name
只上报 source_service 和 target_service，会让 MySQL、Kafka、API 网关全部显示为同级“服务”，彻底掩盖架构意图。每条边必须建模为 DependencyEdge 结构体，关键字段不可省略：
-
Protocol：填"http"/"grpc"/"kafka"/"mysql"，不能是"tcp"或空字符串 -
Port：明确端口号，便于区分同一服务的多个实例（如 MySQL 主从） -
Environment：标注"prod"/"staging"，避免跨环境拓扑混杂 -
Timestamp：精确到毫秒，用于判断边是否过期（如 5 分钟无新上报则标记为 stale）
上报目标建议选轻量级存储：Prometheus Pushgateway（适合短期聚合）、Redis Sorted Set（按时间戳去重）、或专用依赖采集服务（如基于 OpenTelemetry Collector）。
拓扑数据必须由服务自身上报，不能靠中心扫描
所有服务启动时，需向本地内存或中心 registry（如 etcd）注册自身元数据，含 service_name、host、env；每次发起外部依赖调用前，异步记录一条 DependencyEdge（避免阻塞主逻辑）。手动维护依赖列表会迅速过时，唯一可持续的方式是「调用即发现」+「定期心跳刷新」。
容易被忽略的一点是：边的生命周期管理。没有调用就不会产生新边，但旧边不能永远挂着。需要配套的清理机制 —— 比如每个服务定期上报心跳，中心根据最近一次上报时间剔除 stale 边；否则拓扑图会越积越多，最终失去参考价值。
