原生map[uint64]bool并发写必panic，因go map非并发安全；正确解法是分块位图[]uint64配独立mutex，用n>>6定桶、n&63定偏移，避免除法开销，确保原子位操作。
Go 语言里用位图（[]uint64）做海量整数去重，不是“能不能”，而是“怎么避免踩坑”——原生 map[uint64]bool 并发写必 panic，sync.Map 不适合密集整数索引，std::vector<bool></bool> 那种陷阱在 Go 里不存在，但手写位图仍容易在索引计算、内存分配、并发控制三处翻车。
为什么不能直接用 map[uint64]bool 做去重
只要两个 goroutine 同时执行 seen[n] = true，运行时就报 fatal error: concurrent map writes。这不是偶发问题，是确定性崩溃。有人试过只读不写、或加 sync.Once 初始化，都没用——只要有写，就必须保护。而 sync.Map 虽然线程安全，但它底层是哈希分段 + 接口类型擦除，对 uint64 这种固定大小整数来说，开销大、不支持原子位操作、还浪费内存。
[]uint64 位图的索引计算必须用位运算
错误写法：bucket := n / 64; offset := n % 64 —— 除法和取模在热点路径上会触发 x86 微码，比位运算慢一个数量级。正确做法是：bucket := n >> 6; offset := n & 63。这两步必须同时出现，且不能拆成函数调用（编译器未必内联）。设置位时用 bits[bucket] |= (1 ，判断时用 <code>(bits[bucket] & (1 。注意：<code>1 是 <code>int 类型，offset ≥ 32 时会溢出；必须写成 uint64(1) 或 <code>1ULL （后者在 C++ 里常用，Go 中用前者）。
并发安全要分桶锁，不是全局锁
用一个 sync.Mutex 包整个 []uint64，吞吐量卡死在单核水平。真正可行的是分块加锁：mu [numBuckets]sync.Mutex，每个桶（即每个 uint64 元素）配独立锁。写 n 时只锁 mu[n>>6]，不同桶之间完全无竞争。锁数组长度建议和桶数一致，或取其平方根（如 1024 把锁管 100 万桶），避免锁太多造成调度开销。若只做 set 不查，且 Go 版本 ≥ 1.19，可用 atomic.Or64(&bits[idx], uint64(1) 完全免锁；但 <code>Get() 必须读+掩码，无法原子完成，得回退到锁。
预分配内存大小别算错
最大 ID 是 maxID，桶数不是 maxID / 64，而是 (maxID + 63) / 64（即向上取整）。例如 maxID = 1e9，桶数 = (1000000000 + 63) / 64 = 15625000，约 125MB。如果漏加 63，最后一个桶可能没分配，导致 bits[n>>6] 越界 panic。构造时用 make([]uint64, numBuckets)，别用 make([]uint64, 0, numBuckets) —— 后者只是 cap，len 为 0，后续访问 bits[i] 仍 panic。
最易被忽略的点：位图本身不处理负数、超大值、稀疏分布——它只适合非负整数且值域可控的场景；字符串去重必须先哈希再映射，但哈希碰撞得靠布隆过滤器或二级 map 拦截，位图自己不解决冲突。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
