黑白名单过滤器应统一用map[string]struct{}，禁用slice查找；白/黑名单均需预建小写键map，热路径避免重复构建，通配符场景改用专用匹配器。
黑白名单过滤器该用 map 还是 slice？
直接结论：白名单用 map[string]struct{}，黑名单用 map[string]struct{}；别用 []string 做查找——哪怕只有 10 个条目，每次 strings.Contains 或手写遍历都意味着 O(n) 开销，且无法区分大小写策略、前缀匹配等扩展需求。
实操建议：
- 初始化时预建
map[string]struct{}，键统一转小写（或按需保留原始大小写），值用空结构体节省内存 - 若需支持通配符（如
*.example.com），就别硬塞进 map，改用专门的匹配器（如path.Match或自定义 trie） - 避免在热路径（如 HTTP 中间件）里重复构建 map，应作为模块变量或结构体字段一次性初始化
如何让 Filter 方法同时支持域名、路径、Header key 三类输入？
关键不是写三个 if 分支，而是抽象出统一的 MatchFunc 类型：
type MatchFunc func(string) bool
然后为每类输入提供构造函数：
立即学习“go语言免费学习笔记（深入）”；
-
NewDomainWhitelist([]string{"github.com", "gitlab.com"})→ 内部转成小写 map + 返回闭包函数 -
NewPathPrefixBlacklist([]string{"/admin", "/debug"})→ 返回strings.HasPrefix闭包 -
NewHeaderKeyWhitelist([]string{"Content-Type", "Authorization"})→ 区分大小写与否由参数控制
这样 Filter(input string) bool 就只调一次函数，不耦合具体规则类型，也方便单元测试 mock。
为什么不能把黑白名单逻辑写进 HTTP Handler 里？
常见错误：在 http.HandlerFunc 里直接写 if domainInBlacklist(r.Host) { http.Error(...) } ——这导致规则无法复用、无法热更新、无法独立测逻辑。
正确做法是分离关注点：
- 黑白名单本身封装为结构体（如
DomainFilter），带Allow(string) bool和Deny(string) bool方法 - HTTP 中间件只调用该结构体方法，不感知数据来源（文件、DB、env）
- 配置加载（如从 YAML 文件读取）单独做，通过依赖注入传入 filter 实例
否则一旦要支持动态 reload 名单，就得重写整个 handler，而不是只换一个 Reload() 方法。
reload 黑白名单时如何避免请求中断或状态不一致？
最常踩的坑：直接赋值新 map，导致正在执行的 goroutine 读到一半旧数据、一半新数据。
安全做法只有两种：
- 用
sync.RWMutex包裹 map 读写，读操作用RLock()，写操作用Lock()——简单但有锁开销 - 用原子替换：新 map 构建完毕后，用
atomic.StorePointer(&f.rules, unsafe.Pointer(&newMap))（需配合unsafe和指针转换），读侧用atomic.LoadPointer——零停顿，但要求 map 是不可变结构（即新 map 创建后不再修改）
注意：sync.Map 不适合这里——它不支持批量加载和原子全量替换，且遍历性能差，纯属误导性选择。
