microg consul注册静默失败主因是健康检查未配置或consul地址未显式覆盖，需手动添加/health端点、启用健康检查、确保consul先启动；熔断需集成gobreaker并封装至client层；otel traceid跨协议需手动注入extract/inject。
microg 启动时 Consul 注册失败却无报错
服务根本没出现在 Consul UI，日志里也找不到明显错误，app.Run() 调用后进程直接退出或卡住——这是最典型的静默失败。
- 默认健康检查路径是
/health，但microg不自动注册该 endpoint，你得自己加一个 HTTP handler，或者确保 gRPC server 实现了Check方法 -
consul.New()构造时若没显式传入consul.WithHealthCheck(true)，即使 Consul 配置了健康检查，也不会生效 - Consul agent 必须运行在
127.0.0.1:8500（默认地址），只改环境变量CONSUL_HTTP_ADDR没用，必须通过api.DefaultConfig().Address显式覆盖 - 启动顺序必须是：先起 Consul，再起服务；如果 Consul 不可用，
microg默认不重试，会直接失败退出 —— 想容错，得包装registrar加重试逻辑
gRPC 客户端调用超时却不熔断
请求等满 5 秒超时返回错误，后续请求照发，完全没进熔断状态 —— 这不是 bug，是设计如此。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
microg的rpcclient只负责连接管理与超时控制，不内置熔断器；熔断需额外集成sony/gobreaker或resilience-go - 别把熔断逻辑写在业务 handler 里，应该封装到 client 层，对每个下游服务实例维护独立的
CircuitBreaker实例 -
gobreaker.OnStateChange回调不会自动打日志，出问题时很难感知是否真的熔断了，建议加一行log.Info("circuit breaker state changed", "state", newState) -
ReadyToTrip函数判断的是“连续失败次数”，不是“单位时间失败率”，偶发抖动容易误判；若下游不稳定，建议改成基于滑动窗口的失败率统计（需自行扩展）
OpenTelemetry traceID 在 HTTP 和 gRPC 之间丢失
前端发 HTTP 请求进来，经 microg REST server 处理，再 gRPC 调用下游，结果下游日志里的 trace_id 是新生成的，跟上游不一致。
-
microg不自动透传 OTel context，traceID跨协议必须手动注入 - HTTP 入口需从请求 header 提取
traceparent，用otel.GetTextMapPropagator().Extract()构建带 trace 的context.Context - gRPC outbound 调用前，要用
otel.GetTextMapPropagator().Inject()把 trace context 写入metadata.MD，否则下游收不到 - zap 日志字段依赖上下文传递，如果中间某层没把 context 透下去（比如 goroutine 启动时没传），traceID 就断了
服务间通信选型：什么时候用 gRPC，什么时候用 HTTP
不是越快越好，也不是越标准越稳，得看场景。
- 服务间同步调用优先用 gRPC：Protobuf 编码体积小、序列化快、支持流式和双向通信，且
microg对 gRPC 的拦截、重试、超时封装更完整 - 对外暴露 API 或对接第三方系统，用 HTTP/REST：兼容性优先，Swagger/OpenAPI 易生成文档，调试成本低
- 不要在 gRPC 接口里塞大文件上传逻辑 —— gRPC 基于 HTTP/2，但默认有消息大小限制（
grpc.MaxRecvMsgSize），超限直接报status.Code = CodeResourceExhausted - 异步任务或事件广播，一律走消息队列（如 NATS），别用同步通信硬扛，否则下游挂了整个链路就堵死
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
