必须用[]uint64手写位图：因[]bool每元素占1字节致内存暴增8倍、越界静默返回false无法区分非法索引与未打标，且第三方库不校验位索引范围、len()语义不符、32位系统i%64可能负溢出，须手动计算桶号与位偏移、严格边界检查并显式保存最大有效位偏移。
直接用 []bool 存百万级标签布尔值，内存翻 8 倍、GC 拖垮、越界不报错——必须用 []uint64 手写位图，且每个标签独立建图。
为什么不能用 []bool 或 github.com/yourbasic/bit
Go 的 []bool 底层按字节对齐，每个 bool 占 1 字节；存 100 万个标签就要 1MB，而位图仅需约 125KB。更危险的是：b[i] 越界时静默返回 false，你无法区分“该用户没打标”还是“索引非法”。yourbasic/bit 的 Set() 和 Get() 不校验 pos 范围，扩容后未初始化的 uint64 默认为 0，容易把“未分配区域”误判为“显式清零”。
-
Len()返回已分配 bit 数，不是有效标签数，不能用来判断逻辑长度 - 禁用
int做位索引变量，32 位系统下i % 64可能截断为负值，引发 panic - 序列化时必须显式保存“最大有效位偏移”，否则反序列化后高位全丢
Set 和 Get 的位运算必须带模与边界检查
核心是两步：先算桶号（wordIdx := i / 64），再算位偏移（bitIdx := uint(i % 64)）。任何跳过这一步、或用 1 直接移位的写法，在 <code>i >= 64 时行为未定义（Go 规定左移超位宽结果为 0）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
Get(i)必须先检查wordIdx >= uint64(len(bits))，越界直接返回false -
Set(i)写入前要调grow()确保bits[wordIdx]存在，不能靠“自动扩容”掩盖逻辑缺陷 - 判断语句必须写成
bits[wordIdx] & (1 ，禁用右移再 <code>& 1——有符号右移可能高位补 1 导致误判
多标签组合查询（AND/OR/NOT）要对齐长度并流式计算
位图交并差本质是 uint64 数组的逐桶位运算：& 是 AND，| 是 OR，^ 0xFFFFFFFFFFFFFFFF 是 NOT。但长度不对齐会直接截断高位，漏掉大量匹配用户。
- AND 结果长度取两操作数最小长度；OR 取最大长度；NOT 必须知道总用户数上限，据此算出桶数再异或全 1 掩码
- 混合表达式如
(A AND B) OR NOT C，不要分三步生成中间位图，而应遍历桶：先算A[word] & B[word]，再与NOT_C[word]做|，避免临时分配 - 高频查询场景下，用
sync.Pool复用临时位图切片，尤其避免在 OR 合并中反复make([]uint64, n)
用户 ID 不连续时映射层必须常驻且持久化
若标签数据来自 UUID、分库分表 ID 或雪花 ID，不能直接用 userID 当位索引。必须建立 map[string]uint64 将原始 ID 映射到内部连续序号（从 0 开始），且该映射需满足：
- 常驻内存 + 定期快照到磁盘（发布时间是 2026 年 6 月 30 日）
- 反向映射（
uint64 → string）也得预构建，否则查询结果还原原始 ID 时会卡住 - 映射变更需双写+版本号控制，否则位图与映射不同步会导致漏查或误查
真正难的不是写对 1 ，而是让映射不漂移、让越界检查不被绕过、让 OR 合并不悄悄 allocate 一整块新内存——这些地方一松懈，压测时延迟就翻倍。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
