go中[]bool底层按字节存储，每个bool占1字节而非1位，导致空间浪费7/8；应使用[]uint64手动实现bitset，通过i>>6和i&63定位word及位偏移，兼顾性能与内存效率。
为什么 []bool 不是位存储，而你却当它是
Go 的 []bool 底层是按字节（byte）分配的，每个 bool 占 1 字节 —— 不是 1 bit。这意味着存 8 个 bool 要 8 字节，而用位操作可压缩到 1 字节。很多人一上来就写 flags := make([]bool, 1000)，以为内存友好，其实浪费了 7/8 空间。
常见错误现象：len(flags) == 1000 但 unsafe.Sizeof(flags) 显示切片头开销 + 1000 字节底层数组；实际 bit 容量需求可能只有 125 字节。
- 使用场景：布隆过滤器、状态标记数组（如“第 i 个任务是否完成”）、大范围整数存在性检查（如 [0, 10⁶) 内哪些数被标记）
-
[]bool无法直接映射到位，必须用[]byte或uint64数组手动管理 - 别试图用
reflect强转[]bool到[]byte—— Go 运行时会 panic，且语义不保
手写 Bitset：用 []uint64 实现最简高效结构
选 uint64 是因为 64 位对齐友好、CPU 原子操作支持好（如 sync/atomic），且位运算指令（shl, and, or）在现代 CPU 上极快。比 []byte 少 7/8 次内存访问，也比 []uint32 减半索引计算次数。
关键点在于两个坐标换算：
立即学习“go语言免费学习笔记（深入）”；
- 元素索引
i→ 所在 word 下标：i / 64（即i >> 6） - 元素在 word 内偏移：
i % 64（即i & 63） - 设置第 i 位：
bs.words[i>>6] |= 1 - 读取第 i 位：
(bs.words[i>>6] & (1
示例初始化：
type Bitset struct { words []uint64 }<br>func NewBitset(n int) *Bitset {<br> return &Bitset{words: make([]uint64, (n+63)/64)}<br>}
边界处理和扩容陷阱：别让 i >= len*64 悄悄越界
如果只按 (n+63)/64 分配，那么合法索引是 [0, n)，但 Set(1000) 在 NewBitset(1000) 后其实是安全的 —— 因为第 1000 位落在第 1000>>6 == 15 个 word（索引从 0 开始），而 (1000+63)/64 == 16，所以有 16 个 word，下标 0~15 合法。但若调用 Set(1024) 就会 panic：index out of range。
- 容易踩的坑：误以为
len(words)= 最大可存元素数，其实最大可存是len(words) * 64 - 不要在
Set/Get里每次都做if i >= n检查 —— 影响热点路径性能；建议由调用方保证，或提供带检查的SafeSet方法 - 扩容应倍增（如
growTo(n int)），避免每次Set都 realloc；但注意：append一个uint64并不等于“多支持 64 位”，要算清目标 word 数
并发安全要不要加 sync.Mutex？先看场景再决定
纯读多写少、或写操作天然互斥（如单 goroutine 初始化后只读），完全不需要锁。Bitset 本身无内建同步 —— 这不是缺陷，是设计选择。
- 若需并发写同一 bit，
sync/atomic可以用：atomic.Or64(&bs.words[i>>6], 1（要求 Go 1.19+） - 但
atomic.And64清位不安全：它不是“读-改-写”原子，需用atomic.CompareAndSwap64循环实现 - 加
sync.Mutex后，吞吐常掉一个数量级；真需要高并发读写，不如换用roaring.Bitmap这类专门库 - 别为了“看起来线程安全”给每个方法套锁 —— 如果业务逻辑本就不并发访问，锁只是拖慢自己
位操作本身很快，但把注意力全放在“怎么塞进更少内存”上，容易忽略真实瓶颈：比如频繁的 malloc、cache line false sharing、或根本没必要的原子操作。先 profile，再优化。
