健康检查端点必须轻量且无外部依赖，仅检查本地状态和关键依赖；gRPC需配置超时、重试与熔断；配置热更新须避免data race；日志与指标须统一时间源并结构化关联。
服务注册与健康检查必须用 Consul 或 etcd，别手写
自己实现服务发现和心跳检测看似可控，实际会因网络抖动、GC 暂停或 goroutine 泄漏导致误判下线。Consul 的 health check 支持 HTTP/TCP/Script 多种模式，且内置 TTL 自动过期机制；etcd 则依赖 lease + watch 组合，更轻量但需手动续租。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
consul api的Register方法注册时，务必设置Check.TTL（如"10s"），并启动独立 goroutine 定期调用Pass - 避免在
http.HandlerFunc里直接做健康检查逻辑——它可能被超时中断，改用单独的/healthz端点，只检查本地状态（如内存、goroutine 数）和关键依赖（如 Redis 连接池是否可用） - 不要把数据库连通性作为健康检查主项：它会让服务在 DB 故障时集体“失联”，掩盖真实拓扑问题
gRPC 调用必须配超时、重试和熔断，缺一不可
默认的 gRPC client 不带重试，context.WithTimeout 只控制单次调用，网络闪断或服务重启期间容易雪崩。Go 生态中 google.golang.org/grpc/resolver 不处理失败转移，得靠上层补足。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个
grpc.Dial必须传入grpc.WithDefaultCallOptions(grpc.WaitForReady(false))，否则阻塞等待服务上线，拖垮整个启动流程 - 用
github.com/sony/gobreaker做熔断，阈值设为MaxRequests: 10, Interval: 30 * time.Second, Timeout: 5 * time.Second，避免短时间错误放大 - 重试策略用
backoff库，指数退避起始值不小于100ms，最大尝试次数 ≤ 3 —— 再多只是加重下游压力
配置中心要支持热更新，但别让 config struct 直接被并发读写
用 viper.WatchConfig 监听文件或 etcd 变更很常见，但若把解析后的 struct 直接暴露给 handler 使用，可能触发 data race：一个 goroutine 正在更新字段，另一个正在读取。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
sync.RWMutex包裹 config struct，读操作用RLock，写操作用Lock；或者更推荐用atomic.Value存储指针，替换时原子更新，读取零开销 - 禁止在
init()里加载全部配置——微服务启动快，但配置中心响应慢，会导致冷启动失败；改为 lazy load + fallback 默认值 - 敏感配置（如密钥）绝不走文件，统一用
os.Getenv或 Vault 注入，viper 的AutomaticEnv要配合前缀过滤，避免污染
日志和指标必须打到同一生命周期，否则排障时对不上时间线
很多团队分开处理：log 用 zap 打本地文件，metrics 用 prometheus/client_golang 暴露 /metrics，结果故障时发现 log 时间戳比 metrics 晚 8 秒——因为日志异步刷盘、metrics 同步采集，根本无法关联。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有日志 entry 必须带 trace ID 和 span ID，用
ctx.Value透传，且确保zap.Logger的With调用在 request 入口完成，不在中间件里重复加 - 关键指标（如 RPC 延迟、错误率）必须用
promauto.NewHistogram初始化，且 label 值严格匹配 log 中的字段（如 service_name、method、status_code），方便 Grafana 关联查询 - 拒绝用
fmt.Printf或log.Printf打任何生产日志——它们无法结构化，也绕过 zap 的采样和 level 控制
func handleRequest(ctx context.Context, w http.ResponseWriter, r *http.Request) {
// 从 header 提取 traceID，注入 ctx
traceID := r.Header.Get("X-Trace-ID")
ctx = context.WithValue(ctx, "trace_id", traceID)
<pre class='brush:php;toolbar:false;'>// 记录开始时间，用于后续延迟计算
start := time.Now()
// zap 日志必须带 traceID 和 method
logger := zap.L().With(
zap.String("trace_id", traceID),
zap.String("method", r.Method),
)
logger.Info("request started")
// ...业务逻辑...
// metrics 记录，label 与 log 完全一致
requestDuration.With(prometheus.Labels{
"service": "user-api",
"method": r.Method,
"status": "200",
}).Observe(time.Since(start).Seconds())}
最常被忽略的是：健康检查端点本身不能依赖外部组件，也不能参与链路追踪——它要是也去调 DB 或发 HTTP 请求，就失去了快速探活的意义。
