go责任链须定义明确handler接口（如func(*http.request) error），避免interface{}导致运行时panic；需支持提前终止、统一错误语义、本地缓存限流、正确mock测试。
Go 中用 interface{} 实现责任链的典型陷阱
直接用 interface{} 做 Handler 接口参数，看似灵活，实则让编译器失去类型检查能力，运行时容易 panic。比如某个中间件忘记返回 error 或误传了非 *http.Request 类型的值，错误会延迟到链末端才暴露。
- 必须定义明确的 Handler 接口：
type Handler func(*http.Request) error，而非泛型func(interface{}) interface{} - 所有中间件函数签名要严格一致，否则链式调用会编译失败或静默失效
- 不要在链中混用
http.Handler和自定义 Handler —— 它们类型不兼容，强制转换会 panic
反爬规则过滤器如何串联并提前终止
责任链不是“全都要跑一遍”，而是“任一环节返回非 nil error 就立刻中断”。比如 UA 检查失败，就没必要再验 Referer 或请求频率。
- 标准写法是每个 Handler 返回
error，主链循环中用if err != nil { return err }立即退出 - 避免用布尔返回值（如
bool）表示“是否放行”，这会让错误原因丢失，调试时只能看到 “blocked”，看不到 “why” - 如果某规则需记录但不阻断（如打日志后放行），应返回
nil，而非伪造一个errors.New("log only")
IP 频率限制器嵌入责任链的性能隐患
把 redis.Incr 或本地计数器直接塞进 Handler，每请求都查一次 Redis，QPS 上千时延迟飙升、连接池打满。
- 高频规则（如单 IP 每秒请求数）建议用带 TTL 的本地缓存（如
sync.Map+ 时间戳），Redis 只做兜底或持久化 - 不要在 Handler 里新建
redis.Client，复用全局 client 实例；否则 goroutine 泄漏风险高 - 注意 key 设计：IP + 路径前缀（如
/api/）比只用 IP 更精准，避免 /health 拖累主接口限流
测试责任链时 mock 请求头的常见翻车点
写单元测试时用 httptest.NewRequest("GET", "/", nil) 创建请求，默认没有 User-Agent 头，结果 UA 检查逻辑永远走不到“拦截分支”，测了个寂寞。
立即学习“go语言免费学习笔记（深入）”；
- 务必手动设置关键 header：
req.Header.Set("User-Agent", "curl/7.68.0") - 测试被拦截场景，要检查返回的
error是否为预期类型（如ErrBlockedByUA），而不是只断言err != nil - 别忘了测试空 Referer、空 Cookie、超长 URL 等边界 case，这些在真实爬虫流量里很常见
