必须按下游服务维度创建独立 CircuitBreaker 实例，因熔断器是各依赖服务专属“保险丝”，共用会导致故障蔓延；gobreaker.Execute 仅包裹实际网络调用，返回值须为 (interface{}, error)，fallback 需手动触发且签名一致，Timeout/Interval 与单次超时无关，需接入 Prometheus 监控。

直接用 sony/gobreaker，别碰 hystrix-go ——后者已归档、不维护，且其 Do 函数语义模糊，容易把超时和熔断逻辑混在一起，生产环境踩坑率高。

为什么必须按下游服务维度创建独立 CircuitBreaker 实例

熔断器不是全局开关，而是每个依赖服务专属的“保险丝”。共用一个实例会导致 A 服务故障把 B 服务也拖垮。

• 每个 HTTP 客户端、gRPC stub、数据库连接池都应配独立 gobreaker.CircuitBreaker 实例
• 命名必须带服务标识，例如 Name: "payment-service-call" 或 Name: "user-db-query"
• 不要在多个服务间复用同一个 cb 实例，哪怕它们用的是同一套 client 初始化逻辑

gobreaker.Execute 只能包住真正发请求的那一行

常见错误是把整个 http.Client 或 grpc.ClientConn 塞进 Execute，结果它根本没执行任何请求，失败计数永远为 0。

• 正确姿势：只包裹 client.Do(req)、stub.GetUser(ctx, req) 这类实际发起网络调用的动作
• 返回值必须是 (interface{}, error)：成功时返回结果（哪怕是 nil），失败时返回非 nil 错误
• HTTP 5xx、context.DeadlineExceeded、grpc codes.Unavailable 都要主动转成 error，否则不计入失败统计
• 别在 Execute 内做重试、打日志、上报 metric ——这些会污染失败判定逻辑

fallback 不是自动触发的降级入口

gobreaker.Execute 的第三个参数（fallback）只在两种情况触发：熔断器处于 Open 状态（返回 gobreaker.ErrOpen），或主函数 panic。它不会捕获超时、503、context canceled 等常规错误。

Colly Golang Web Scraper and Crawler Framework

Colly 是一个用于 Go 语言的快速开源爬取和爬虫框架。它适用于从简单的页面提取到异步爬虫处理大量页面集合，支持请求回调和结构化解析。

下载

立即学习“go语言免费学习笔记（深入）”；

• 降级逻辑必须手动写：先判断 errors.Is(err, gobreaker.ErrOpen)，再显式调用你的 fallback 函数
• fallback 函数签名必须和主函数完全一致，例如主函数是 func() (*User, error)，fallback 也得是这个类型
• 内部禁止访问 DB、调其他服务、起 goroutine；推荐从 sync.Map 或本地 LRU cache 读缓存，或用 DefaultUser() 构造静态响应
• 返回 &User{} 是危险的——序列化后是 {"name":"","age":0}，前端可能当成真实空数据；应显式初始化字段

Timeout 和 Interval 不是单次调用超时时间

Timeout 是“熔断后多久尝试半开”，Interval 是“滑动窗口多长时间重置”，二者都跟单次调用超时无关。设错会导致恢复延迟或误判抖动。

• Timeout 建议设 15 * time.Second：太短（如 5s）会让半开探测过于激进；太长（如 60s）下游已恢复，你还在休眠
• Interval 控制失败率统计周期，选 30s ~ 2m；设成 5s 容易把一次网络抖动当持续故障
• MaxRequests 别设 1：半开刚进就因单次失败又切回 Open，实际建议 ≥10
• 单次调用超时必须用 context.WithTimeout 单独控制，和熔断器解耦

最容易被忽略的是指标暴露：gobreaker.Metrics 必须接入 Prometheus，否则你无法知道它什么时候开了、为什么开、fallback 是否被频繁触发。重点盯 circuit_breaker_state、circuit_breaker_requests_total 和 circuit_breaker_fallback_total ——没监控的熔断，等于在黑盒里拉闸。