热路径位运算提速需消除分支、避免越界检查、用查表替代循环；GetBit/SetBit因含条件分支或panic被Go编译器拒内联；应预分配足量[]uint64，将校验下沉至非热路径或debug模式验证内联。
热路径上的位运算不能靠“写得短”提速，必须消除分支、避免越界检查、用查表替代循环扫描——否则编译器根本不会内联，CPU流水线也会频繁中断。
为什么GetBit和SetBit在热点里总被反复拒绝内联
Go 编译器对含条件分支或潜在 panic 的函数直接拒内联，哪怕你加了//go:inline。而手写位图里最常写的if wordIdx >= uint64(len(b.bits)) { return false }就是典型触发点：它生成跳转指令，破坏 CPU 流水线；同时让函数逃逸分析失败，导致无法内联。
- 别在热路径做运行时边界校验——初始化时就按
(total + 63) / 64分配足量[]uint64，让wordIdx天然不越界 - 把校验逻辑下沉到非热路径（如
Expand方法），或只在 debug 模式用debug.SetGCPercent(-1)配合assert宏包裹 - 确认是否真被内联：用
go build -gcflags="-m=2" main.go 2>&1 | grep "inlining call to GetBit"，没输出就等于没生效
m2id查表怎么让ID分配从O(8)降到O(1)
分配下一个空闲 ID 本质是找字节中第一个为 0 的 bit 位。朴素写法用for j := 0; j 扫描，每次最多 8 次判断；而<code>m2id是预计算的 256 元素数组，m2id[b]直接返回字节b里最低空闲位索引。
- 查表初始化只需一次：
var m2id [256]uint8在包级变量定义，init()里填满 - 使用时：先取字节
byteVal := b.bits[wordIdx]，再查bitPos := m2id[byteVal]，最后ID = wordIdx*64 + uint64(bitPos) - 注意：该优化只对
[]byte粒度有效；若你用[]uint64，需先提取低 8 位再查表，或改用bits.TrailingZeros64（但后者在 ARM 上可能无硬件支持）
并发写同一uint64桶时，atomic.OrUint64比锁快在哪
多个 goroutine 同时调用SetBit写同一个uint64元素（即wordIdx相同），用互斥锁会串行化；而atomic.OrUint64(&b.bits[wordIdx], 1是单条 CPU 指令（如 x86 的<code>orq + lock前缀），无上下文切换、无调度延迟。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 必须确保
1是<code>uint64类型——写成1 或<code>uint64(1) ，否则在 32 位环境右移超 31 位会静默截断 - 读操作仍可用普通 load（
b.bits[wordIdx]），因 OR 是幂等的，读到中间态也只影响“是否已设置”的判断精度，不破坏数据一致性 - 别对整个
BitMap结构体加sync.Mutex——锁粒度太大，热点下会成为瓶颈
什么时候该停手，换 roaringbitmap
手写[]uint64位图在 ID 空间密集（比如用户 ID 连续）、标签数uint64桶全为 0，内存暴涨且 AND 操作要遍历所有桶。
此时 roaringbitmap 自动分块+RLE压缩，Cardinality()是 O(1)，AND/OR 也只在非空块上计算——不是它“更聪明”，而是它把“跳过全零桶”这件事固化进了数据结构设计里。别等 OOM 才切，看len(bits)是否持续 > total/64 * 1.5 就该预警。
