Go过滤器动态替换需用atomic.Value存指针实现无锁切换，构造时注入配置、禁止持有状态，重载须“先建后切”并显式关闭旧资源。
过滤器接口必须支持运行时替换
Go 没有类加载机制，所谓“动态重载”本质是用新实例替换旧实例，同时保证调用方无感知。关键在于定义一个干净、无状态、可安全并发替换的接口：
-
Filter接口只暴露Apply(context.Context, interface{}) (interface{}, error)方法，避免持有任何内部状态或依赖外部单例 - 所有配置（如正则表达式、白名单列表）必须在构造时传入，而非从全局变量或
init()读取 - 不要让过滤器实现
http.Handler或直接持有*http.ServeMux—— 这会绑定生命周期，阻碍替换 - 如果需共享缓存（如规则编译后的
*regexp.Regexp），用sync.Once初始化，但禁止在Apply中修改它
用原子指针管理当前活跃过滤器实例
靠 sync/atomic 替换函数指针或接口值，比锁更轻量，且能保证调用端看到的始终是完整、已初始化的实例：
type FilterManager struct {
filter atomic.Value // 存储 *MyFilter 实例
}
func (m *FilterManager) Set(f Filter) {
m.filter.Store(&f) // 注意：Store 的是地址，不是值拷贝
}
func (m *FilterManager) Apply(ctx context.Context, in interface{}) (interface{}, error) {
f, ok := m.filter.Load().(*Filter)
if !ok {
return in, errors.New("no active filter")
}
return (*f).Apply(ctx, in)
}
注意：atomic.Value 不能直接存接口类型（因底层复制可能不安全），推荐存指针；Load() 后必须做类型断言，且断言失败说明 Set() 尚未完成，应返回明确错误而非 panic
重载时如何避免请求中断或状态错乱
重载不是“删旧建新”，而是“先建后切”。常见错误是直接在 Set() 里解析 YAML 并 new 实例 —— 若解析失败，会导致 filter 置空，后续请求全部失败：
立即学习“go语言免费学习笔记（深入）”；
- 重载逻辑必须在
Set()外部完成：先调用NewFilterFromConfig()构造新实例，确认无误后再m.Set(newF) - 若配置来自文件，监听
fsnotify事件后，应在 goroutine 中异步加载并校验（如检查正则语法、URL 可达性），成功后再切换 - 不要在
Apply()中加锁判断配置变更 —— 这会拖慢所有请求；原子替换本身已提供线程安全的切换语义 - 对耗时操作（如远程拉取规则列表），考虑加超时和降级：加载失败时保留旧实例，并记录 warning 日志
测试重载是否真正生效
光看日志或配置文件更新没用。验证点要落在行为上：
- 写一个单元测试：启动两个不同规则的
Filter实例（比如一个放行"admin"，一个拦截"test"），用Set()切换后，立即调用Apply()断言结果符合新规则 - 用
runtime.GC()+debug.ReadGCStats()观察旧实例是否被回收（需确保无闭包引用或 goroutine 持有） - 压测时发请求的同时触发重载，检查
pprof中goroutine数是否突增（说明有旧过滤器 goroutine 卡住未退出） - 如果过滤器内启了后台 goroutine（如定期刷新 token），必须提供
Close() error方法，并在Set()前显式调用旧实例的Close()
最常被忽略的是：重载后旧实例的资源泄漏。比如一个过滤器开了 time.Ticker 却没 stop，它会一直跑下去，消耗 CPU 和内存。
