Go bloom 合并Bloom过滤器为什么要求参数一致

Go 使用 github.com/bits-and-blooms/bloom/v3 合并 Bloom 过滤器时，关键不是两个过滤器“都叫 Bloom”，而是它们必须拥有相同的位数组长度 m 和哈希函数数量 k。因为 Merge 的本质是把两组位做按位或，只有位坐标和哈希位置的含义一致，合并后的 Test 结果才有意义。

官方地址：https://pkg.go.dev/github.com/bits-and-blooms/bloom/v3

分片过滤器应该在同一个参数合同下创建：容量估算可以按各分片规划，但最终传给 New 的 m、k 必须一致。参数不同就不要强行合并，先统一创建策略或重新构造过滤器。

• 一致项：Cap() 对应的位数 m，以及 K() 返回的哈希函数数量 k。
• 合并动作：left.Merge(right) 修改左侧过滤器，并返回可能的参数错误。
• 结果边界：Bloom 过滤器只保证实际存在的元素不会被报成不存在，true 仍可能是假阳性。

我遇到的症状：Merge 为什么要求 m 和 k 一致

我在把两个分片过滤器合到一个查询对象时，最容易先看见的是 Merge 返回错误，而不是查询结果异常。回到结构上看，一个 Bloom 过滤器可以看成长度为 m 的位集合；加入一个键时，库会用 k 个哈希位置在这组位上置位。两个过滤器只有在位集合长度相同、同一个键使用的哈希位置规则相同时，按位或才仍然代表两个集合的并集。

因此，容量 m 不只是内存大小，k 也不只是性能参数，它们共同定义了一个过滤器的形状。不同形状的位数组即使都来自同一个包，也不能直接当成同一坐标系。

时间线：先统一参数，再把分片合并

我会把参数计算放在分片创建之前，再把同一组 m、k 传给每个分片。下面的示例故意使用 New，让合并合同直接可见；实际项目也可以先用 EstimateParameters 得到 m、k，再统一传入。

package main

import (
	"fmt"

	"github.com/bits-and-blooms/bloom/v3"
)

func main() {
	// m 和 k 是所有分片共同遵守的过滤器形状。
	const m uint = 1_000_000
	const k uint = 7

	left := bloom.New(m, k)
	right := bloom.New(m, k)
	left.AddString("user:1001")
	right.AddString("user:2002")

	// Merge 会把 right 的位合并到 left，并返回参数不匹配错误。
	if err := left.Merge(right); err != nil {
		fmt.Printf("merge bloom filters: %v\\n", err)
		return
	}

	// 合并后的过滤器用于查询两个分片曾经写入的键。
	fmt.Println(left.TestString("user:1001"))
	fmt.Println(left.TestString("user:2002"))
}

这里的 Merge 是就地操作：左侧对象保留合并结果，右侧对象仍可独立使用。不要把返回值当作新的过滤器；方法签名返回的是 error，所以必须保留错误处理。

根因：参数不一致与容量误区是两件事

最直接的错误是一个过滤器用 bloom.New(1_000_000, 7)，另一个用不同的 m 或 k。此时即使两者都已经加入了相同类型的键，也不能安全合并。正确做法是让创建配置来自同一个结构体、配置文件或参数计算函数，而不是在各个 worker 中分别估算。

还要区分“参数一致”和“容量足够”。多个过滤器可以拥有同样的 m、k，但如果预计元素数量长期超过容量，整体误判率仍会升高。官方文档明确提示 Bloom 过滤器不是动态扩容结构，容量应该在创建时保守规划；合并不会把位数组自动扩容，也不会重新计算更合适的 k。

修复与防复发：把合同和资源边界一起保存

如果过滤器需要跨进程或跨节点传递，可以使用库提供的二进制读写能力，但接收端仍要把序列化数据当作同一参数合同的一部分管理。不要只传位数据而丢掉 m、k 的配置元信息，否则后续合并很难判断形状是否兼容。

另外，包文档说明同一个过滤器默认不适合被多个 goroutine 同时访问；如果一边 Merge 或 Add，一边 Test，应由单一 owner、channel 或互斥锁串行化。统一 m、k 只能解决数据结构兼容，不能替代并发保护。

常见问题

两个过滤器的元素数量不同，可以 Merge 吗？

可以。元素数量不是 Merge 的形状合同，只要 m、k 和哈希规则一致即可；但总元素数量变大后，误判率可能高于最初设计目标。

只要 m 一样、k 不一样也能合并吗？

不能。k 决定一个键会检查或设置多少个哈希位置，k 不同会改变位集合的语义，应该重新按统一参数创建。

Merge 后为什么还会出现不存在的键为 true？

这是 Bloom 过滤器的正常假阳性边界。false 可以排除键存在，true 只能表示可能存在，不能替代精确集合查询。