必须用[]uint64手写位图且每个标签独立建图，因[]bool内存翻8倍、越界不报错、yourbasic/bit无边界检查易误判；位运算须先算桶号再算位偏移，并严格校验索引与扩容。
直接用 []bool 存百万级标签布尔值，内存占用翻 8 倍、GC 拖垮、越界不报错——必须用 []uint64 手写位图，且每个标签独立建图。
为什么不能用 []bool 或 github.com/yourbasic/bit
Go 的 []bool 底层按字节对齐，每个 bool 占 1 字节；存 100 万个标签就要 1MB，而位图仅需约 125KB。更危险的是：访问 b[i] 越界时静默返回 false，你无法区分“该用户没打标”还是“索引非法”。yourbasic/bit 的 Set() 和 Get() 不校验 pos 范围，扩容后未初始化的 uint64 默认为 0，容易把“未分配区域”误判为“显式清零”。
- 别依赖
Len()判断逻辑长度——它返回已分配 bit 数，不是有效标签数 - 禁止用
int做位索引变量，32 位系统下i % 64可能截断为负值，引发 panic - 序列化时必须显式保存“最大有效位偏移”，否则反序列化后高位全丢
Set 和 Get 的位运算必须带模与边界检查
核心是两步：先算桶号（wordIdx := i / 64），再算位偏移（bitIdx := uint(i % 64)）。任何跳过这一步、或用 1 直接移位的写法，在 <code>i >= 64 时行为未定义（Go 规定左移超位宽结果为 0）。
-
Get(i)必须先检查wordIdx >= uint64(len(bits))，越界直接返回false -
Set(i)写入前要调grow()确保bits[wordIdx]存在，不能靠“自动扩容”掩盖逻辑缺陷 - 判断语句必须写成
bits[wordIdx] & (1 ，禁用右移再 <code>& 1——有符号右移可能高位补 1 导致误判
多标签组合查询（AND/OR/NOT）要对齐长度并流式计算
位图交并差本质是 uint64 数组的逐桶位运算：& 是 AND，| 是 OR，^ 0xFFFFFFFFFFFFFFFF 是 NOT。但长度不对齐会直接截断高位，漏掉大量匹配用户。
立即学习“go语言免费学习笔记（深入）”；
- AND 结果长度取两操作数最小长度；OR 取最大长度；NOT 必须知道总用户数上限，据此算出桶数再异或全 1 掩码
- 混合表达式如
(A AND B) OR NOT C，不要分三步生成中间位图，而应遍历桶：先算A[word] & B[word]，再与NOT_C[word]做|，避免临时分配 - 高频查询场景下，用
sync.Pool复用临时位图切片，尤其避免在OR合并中反复make([]uint64, n)
用户 ID 不连续时映射层必须常驻且持久化
若标签数据来自 UUID、分库分表 ID 或雪花 ID，不能直接用 userID 当位索引。必须建立 map[string]uint64 将原始 ID 映射到内部连续序号（从 0 开始），且该映射需满足：
- 常驻内存 + 定期快照到磁盘，否则服务重启后位图失效
- 映射写入需与位图写入同事务（如 Kafka 消费位点 + DB UPSERT 一起提交）
- 删除用户不是“置反位”，而是清对应位，并确保下游过滤逻辑不依赖已删 ID 的状态
最易被忽略的一点：标签基数必须严格控制在 distinct_count / total_users （即 1%），否则位图稀疏、内存爆炸、AND 运算变慢——像 <code>user_id 或 nickname 这类高基数字段，位图完全不适用。
