RoaringBitmap不是语言学习技巧，而是第三方库；影响位图索引性能的是Go对内存布局、位运算和并发的理解；手写[]uint64+位运算更可控高效；[]bool和yourbasic/bit存在内存浪费、越界静默、未初始化等问题；必须显式校验桶号与位偏移，禁用int索引，统一用uint类型并严格边界检查。
roaringbitmap 不是“语言学习技巧”，它是第三方库；真正影响位图索引性能的，是 Go 本身对内存布局、位运算和并发模型的理解与运用。直接上手写 []uint64 + 位运算，比套用任何“技巧”都更可控、更快。
为什么不能靠 []bool 或 yourbasic/bit 搞定位图索引
常见错误是把“能跑通”当成“能上线”：[]bool 在百万级数据下内存翻 8 倍、GC 压力陡增、越界访问静默返回 false，你根本分不清是“没打标”还是“索引错”。yourbasic/bit 的 Set() 和 Get() 不校验 pos 范围，扩容后未初始化的 uint64 默认为 0，容易把 padding 当业务数据。
-
Len()返回的是已分配 bit 数，不是逻辑有效长度 - 用
int做位索引变量，在 32 位环境或超2^31场景下会截断溢出 - 序列化时只存数据不存
lenBits，反序列化后高位全丢
[]uint64 手写位图的边界检查必须写死在 Set/Get 里
别信“自动扩容”或“默认安全”，生产环境的位图必须显式控制生命周期。核心是两步：先算桶号，再算位偏移，并且每一步都带校验。
-
wordIdx := i / 64和bitIdx := uint(i % 64)—— 必须用uint64或uint类型，禁用int -
Get(i)前必须检查wordIdx >= uint64(len(bits))，越界直接返回false -
Set(i)前调expandTo(wordIdx)预分配，避免append触发多次 copy - 读取写入统一用
bits[wordIdx] & (1 ，禁用右移（有符号右移可能补 1）
多条件组合查询时，位图合并必须对齐长度并流式计算
AND/OR/NOT 不是简单调库函数，瓶颈常在内存分配和长度错位。例如 A AND B 若长度不一致，Go 版 roaringbitmap 会截断到较短者，漏掉大量匹配项。
-
AND结果长度取两操作数最小长度；OR取最大长度；NOT必须按总用户数上限算出桶数，再异或全 1 掩码 - 混合表达式如
(A AND B) OR NOT C，不要分三步生成中间位图，而应遍历桶：先算A[word] & B[word]，再与NOT_C[word]做| - 高频场景下用
sync.Pool复用临时[]uint64切片，尤其避免在OR合并中反复make([]uint64, n)
原始 ID 不连续时，映射层必须常驻且可快照
标签来自 UUID、雪花 ID 或分库分表 ID？那绝不能把原始 ID 直接当位索引。必须构建 map[string]uint64 将其映射为紧凑连续序号（从 0 开始），且该映射不是一次性的中间结构。
立即学习“go语言免费学习笔记（深入）”；
- 映射需常驻内存，不能每次查询重建
- 需支持增量更新和定期快照到磁盘，否则重启后位图失效
- 反向映射（
compactID → originalID）也得预构建，查询结果还原才够快 - 若用 roaringbitmap，务必先完成这层映射，再喂给
roaring.Bitmap，否则Add()传入稀疏 ID 会导致位图膨胀失控
