Go用[]uint64可高效实现位图索引：需分配(n+63)/64个uint64避免越界，访问第i位时定位字索引i/64与位偏移i%64，再用bits[idx] & (1 << off) != 0判断。
Go 语言本身不提供内置位图索引（Bitmap Index）类型，但用 []uint64 配合位运算能高效实现——关键不是“能不能”，而是“怎么避免越界、对齐和并发误写”。
如何用 []uint64 表示 100 万个布尔值
位图本质是压缩布尔数组：每 bit 存一个标志。Go 中最自然的载体是 []uint64，因为每个 uint64 可存 64 个 bit。
计算所需切片长度：向上取整 (n + 63) / 64，不能直接用 n / 64（否则少分配最后一个元素）。
- 错误写法：
make([]uint64, n/64)→ 当n=65时只分配 1 个uint64，但需要 2 个 - 正确写法：
make([]uint64, (n+63)/64) - 访问第
i位：先算所在字（i / 64），再算偏移（i % 64），最后用bits & (1 判断
Set() 和 Get() 的边界检查必须做
没做下标检查的位图在越界写入时不会 panic，而是静默污染相邻 uint64 的其他 bit，导致后续读取全乱——这是最隐蔽也最常踩的坑。
立即学习“go语言免费学习笔记（深入）”；
- 所有公开方法（
Set、Get、Clear）第一行应校验i >= 0 && i -
b.Len()应返回len(b.bits) * 64，而非len(b.bits) - 若性能敏感且调用方已保证合法索引，可提供不检查的内部方法（如
setUnchecked），但绝不暴露给外部
并发写入时不能只靠 sync.Mutex
单个 uint64 上不同 bit 的并发写（比如两个 goroutine 分别 set 第 3 和第 12 bit）理论上安全，但 Go 的内存模型不保证这种“部分写”原子性；实际中因编译器重排或 CPU 缓存未刷新，仍可能出错。
- 简单场景：整个位图用
sync.RWMutex保护，读多写少时用RWMutex提升读性能 - 高并发写场景：按
uint64粒度分段加锁（例如每 64 位一个sync.Mutex），避免锁争用 - 绝对不要依赖
atomic.StoreUint64直接写整个uint64来 set 单 bit——它会覆盖其他 bit
为什么不用 github.com/bits-and-blooms/bitset
这个库功能完整，但默认使用 []uint64 + 手动位运算，和手写差别不大；真正要注意的是它默认不检查索引，且 Set() 接口接受 uint 而非 int，容易和 Go 常见的 int 索引混用导致溢出。
- 如果项目已引入该库，务必封装一层：接收
int参数，做范围检查后再转uint调用 - 若只是临时需要轻量位图，手写 50 行以内更可控——没有依赖、无隐式扩容、逻辑一目了然
- 该库的
Count()方法用popcount指令优化，手写时可用bits.OnesCount64()达到同等性能
位图索引真正的复杂点不在结构设计，而在“什么时候该用它”：等值查询快，范围查询慢，字符串字段不适合——这些决策比代码实现更影响最终效果。
