闭包函数工厂比结构体+方法更适合生成分词过滤规则，因为其核心差异仅在少数固化参数（如最小词长、权重阈值），闭包可轻量捕获并冻结这些值，无内存分配、零字段可变性、天然线程安全；而结构体易被并发修改或引发GC压力，且不适用于“创建即固化”的场景。
闭包函数工厂为什么比结构体+方法更适合生成分词过滤规则
因为分词过滤规则的核心差异往往只在几个参数（比如最小词长、是否忽略空格、是否启用同音替换），而这些参数一旦确定就不再变化；用闭包捕获它们，比每次 new 一个 struct 实例更轻量、无内存分配开销、且天然线程安全（只要不共享可变状态）。结构体适合需要频繁修改字段的场景，而过滤规则是“创建即固化”的典型用例。
常见错误现象：func NewFilter(minLen int) *Filter 返回指针后，在高并发下被意外修改 minLen 字段，导致规则错乱；或为每个请求 &Filter{...} 分配对象，GC 压力陡增。
- 闭包工厂返回的是纯函数值，无字段可改，杜绝运行时篡改
- 参数通过闭包捕获进函数环境，无需传参，调用时零开销
- 同一组参数生成的多个闭包实例彼此隔离，
counter()类比可理解：每个newFilter(2)和newFilter(3)互不影响
如何用闭包封装带权重的敏感词匹配逻辑
权重不能在匹配时临时查 map 或数据库——那会把 O(n) 扫描变成 O(n×m)，直接拖垮性能。正确做法是把权重“烧进”闭包环境，在构建时就确定行为分支。
使用场景：对“王八”打标警告（weight=3）、对“王八羔子”直接拦截（weight=10），两者共存且需重叠匹配。
立即学习“go语言免费学习笔记（深入）”；
- 工厂函数签名应为
func(weightThreshold int) func(string) []MatchResult，把阈值固化进闭包 - 闭包内部只做 Trie 扫描，收集所有
MatchResult（含位置、词、原始权重），不在此刻判断动作 - 动作 dispatch 提到闭包外层：比如
if r.Weight >= weightThreshold { return ActionBlock }，避免匹配循环内分支预测失败 - 不要在闭包里存
*Trie指针并反复修改其状态——每次调用必须从根节点开始，否则并发下current节点会串
循环中生成多个过滤闭包时的变量捕获陷阱
这是最常踩的坑：用 for 循环批量注册不同阈值的过滤器，结果全部闭包都用了最后一个 i 值。
错误写法示例：
var filters []func(string) bool
for i := 3; i <= 10; i += 2 {
filters = append(filters, func(s string) bool {
return containsWeighted(s, i) // 所有闭包都捕获同一个 i，最终值为 11
})
}
正确做法是立即创建局部副本：
for i := 3; i <= 10; i += 2 {
threshold := i // 显式声明局部变量
filters = append(filters, func(s string) bool {
return containsWeighted(s, threshold)
})
}
- Go 编译器不会自动为循环变量创建副本，必须手动声明
- 如果阈值来自配置切片，建议用索引访问而非值遍历：
for idx := range thresholds { t := thresholds[idx] ... } - 闭包捕获的是变量地址，不是值——这点和 JavaScript 不同，务必注意
热更新过滤规则时闭包工厂的原子性边界
闭包本身不可变，但工厂函数可以返回新闭包。热更新的关键不是“改闭包”，而是“换闭包”。
容易被忽略的地方：更新后旧闭包可能还在处理未完成请求，若新旧规则依赖同一份共享数据（如全局 *Trie），而 Trie 正在重建，就会 panic。
- 必须原子替换整个工厂函数变量：
var activeFilter func(string) []MatchResult，用atomic.StorePointer或sync.RWMutex保护赋值 - 新闭包应持有重建后的 Trie 实例指针，而不是复用旧指针
- 不要试图在闭包内做“懒加载 Trie”——
if trie == nil { trie = build() }在并发下会触发多次构建，且存在竞态 - 闭包工厂的输入参数（如词典路径、权重配置）应在调用前校验完毕，避免闭包执行时才发现文件不存在
