健康检查接口返回 200 但服务实际不可用？别只看 HTTP 状态码
HTTP 状态码 200 只代表 handler 没 panic，不等于依赖就绪。常见错误是直接在 http.HandleFunc("/health", ...) 里硬写 w.WriteHeader(200)，忽略数据库连接、下游 gRPC 服务、Redis 连通性等真实依赖。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
healthcheck包（如github.com/alexliesenfeld/health）或自建分层检查：基础层（进程存活）、依赖层（DB、Redis、gRPC client.Conn().Ready()）、业务层（关键查询耗时 - 每个子检查必须设超时，例如
ctx, cancel := context.WithTimeout(r.Context(), 2*time.Second)，避免整个健康接口被一个慢依赖拖死 - 返回体里显式带各依赖状态，比如
{"db": "ok", "redis": "timeout", "grpc_user_svc": "ok"}，方便运维快速定位
time.Now().UnixNano() 做指标时间戳？小心纳秒级精度引发的聚合错乱
微服务指标打点若直接用 time.Now().UnixNano() 当时间戳，在 Prometheus 中做 rate() 或 histogram_quantile() 时，因采集周期（如 15s）远大于纳秒精度，会导致样本对齐失败、速率计算为 0 或突刺。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有指标时间戳统一用秒级或毫秒级：
time.Now().Unix()或time.Now().UnixMilli()（Go 1.17+） - 如果用 OpenTelemetry 打点，确保
metric.Meter.RecordBatch()的time.Time参数已截断到毫秒，不要传原始time.Now() - 在 Grafana 查看
rate(my_service_latency_seconds_count[5m])前，先确认 Prometheus 抓取间隔和指标时间戳粒度是否匹配
用 sync.Map 缓存健康评分？并发安全≠适合高频读写场景
有人把每秒更新的 CPU、内存、请求延迟、错误率等指标塞进 sync.Map，再由健康评估函数读取计算综合分。结果发现 CPU 占用飙升，sync.Map 的 read map 频繁扩容反而比普通 map + sync.RWMutex 更慢。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 健康指标数据写入频率低（map + sync.RWMutex，代码更可控，profile 也更清晰
- 若真需要无锁，改用
fastmap（非标准库）或定期批量更新 + 原子指针切换（atomic.StorePointer），避免在热路径上反复调用sync.Map.Load/Store - 评分计算本身应尽量无锁：把当前指标快照 copy 到局部 struct，再算分，别边读边算
综合评分公式里硬编码权重？上线后没法动态调参
写死 score = 0.4*cpu + 0.3*latency_ratio + 0.3*error_rate，看似简单，但服务迭代后，可能发现错误率影响远超预期，或某次发布后延迟毛刺变多——此时得改代码、发版、重启，健康评估直接断档。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 权重配置走外部源：环境变量（
HEALTH_WEIGHT_CPU=0.25）、Consul KV、或轻量配置中心（如viper+ YAML 文件热加载） - 评分函数接收
Weights struct{ CPU, Latency, Error float64 }参数，运行时注入，避免重编译 - 加一层校验：权重和必须 ≈ 1.0（允许 ±0.01 浮点误差），否则日志告警并 fallback 到默认权重，防止配置错误导致评分失真
健康度不是个“能返回 JSON 就算好”的功能，它背后的时间精度、并发模型、配置可变性、依赖隔离，每一处松动都会在流量高峰时暴露。最常被跳过的，是给每个子检查加独立超时，以及让权重脱离二进制。
