Go微服务容错需协同超时控制、熔断降级、智能重试与服务发现：超时用context.WithTimeout设边界；熔断器依错误率切换状态；重试仅针对临时错误并指数退避；降级提供无依赖兜底；全链路可观测。
在 Go 微服务架构中，容错机制不是“加个重试就行”，而是需要结合超时控制、熔断降级、重试策略与服务发现协同设计。核心目标是：单个依赖故障不扩散、响应可预期、关键路径有兜底。
超时与上下文控制：阻断慢调用蔓延
HTTP 或 gRPC 调用若无超时，会持续占用 goroutine 和连接资源，引发级联超时。必须为每个外部依赖设置明确的超时边界。
- 使用 context.WithTimeout 包裹所有下游调用，超时时间需小于上游接口的 SLA（例如上游要求 200ms，下游调用设为 150ms）
- 避免在 handler 中复用同一个 context.Background()；每个请求应携带独立的 context，并透传至所有依赖层
- 对数据库、Redis 等中间件客户端，也要配置连接超时、读写超时（如 sql.Open 中的
SetConnMaxLifetime 和 SetReadDeadline）
熔断器（Circuit Breaker）：自动隔离不稳定依赖
当某服务错误率持续超标（如 5 秒内失败 5 次），熔断器应主动跳闸，直接返回降级逻辑，避免无效重试消耗资源。
- 推荐使用 sony/gobreaker 或 afex/hystrix-go（后者已归档但代码稳定）
- 配置三个状态：Closed（正常调用）、Op
en（拒绝请求，直接降级）、Half-Open（试探性放行少量请求验证恢复）
- 熔断恢复后，首次成功调用不应立即全量放行，而应逐步增加流量（可配合指数退避探测）
智能重试 + 指数退避：避免雪崩式重压
重试只对临时性错误（如网络抖动、503）有效；对业务错误（400、404）或熔断状态，重试只会加重问题。
- 仅对可重试错误码（如 500、502、504、timeout、connection refused）启用重试
- 使用 backoff.Retry（github.com/cenkalti/backoff）实现带 jitter 的指数退避，避免重试请求同时到达下游
- 限制最大重试次数（通常 2–3 次），并在日志中标记重试行为（如
retry=2/3），便于链路追踪定位
降级与兜底：保障核心流程可用
当熔断触发或重试耗尽，必须提供有意义的降级响应，而非抛错中断用户流程。
- 按业务重要性分级：核心接口（如支付下单）可返回缓存旧数据或默认值；非核心（如推荐位）可直接空渲染
- 降级逻辑需轻量、无外部依赖（不能在降级里再调 Redis 或 DB）；建议预加载静态兜底数据或使用内存 map 缓存
- 通过配置中心（如 Nacos、Consul）动态开关降级策略，故障时人工一键开启，恢复后平滑关闭
不复杂但容易忽略：容错能力必须可观测。每个熔断器状态、重试次数、降级触发量，都要打点到 Prometheus，并配置告警阈值。没有监控的容错，等于没做。
