应使用uint64而非int存储权限位，因int在32位系统仅32位，无法容纳64种独立权限；uint64提供稳定64位无符号空间，避免右移补码问题，位运算语义确定，而int64负数右移行为在go版本间可能不一致。
为什么用 uint64 而不是 int 存储权限位
Go 的 int 在 32 位系统上只有 32 位，而权限位常需支持 64 种独立操作（如读/写/删/管理/审计等），uint64 提供稳定 64 位空间，且无符号特性避免右移补码问题。若用 int64，负数右移行为在不同 Go 版本中可能不一致；uint64 的位运算语义完全确定。
常见错误是直接用 int 做位掩码：permission & 1 在 32 位环境会溢出为 0，导致权限永远判 false。实操建议：
- 所有权限常量统一定义为
uint64类型，例如：const PermRead uint64 = 1 - 权限集合变量声明为
uint64，而非int或uint（后者宽度不固定） - 避免用
math.MaxUint64初始化全权限，直接写^uint64(0)—— 更快且无依赖
HasPerm 函数为何必须用 & 而非 ==
权限检查本质是「是否包含某子集」，不是「是否完全相等」。userPerms & requiredPerm == requiredPerm 是常见误写，它在 requiredPerm == 0 时恒为 true（任何数 & 0 都是 0），造成空权限绕过。正确逻辑是：userPerms & requiredPerm != 0 判断是否存在交集，或更严格地：userPerms & requiredPerm == requiredPerm 判断是否完整包含。
性能关键点：前者单次与运算 + 非零判断，后者多一次等值比较。多数场景用前者即可，除非你明确要求「必须精确匹配该权限位（不允许多）」。示例：
func HasPerm(perms, p uint64) bool {
return perms&p != 0 // 快，且语义清晰：只要 p 对应的任意一位被置 1 就返回 true
}
注意：p 必须是单个权限位（如 PermRead），不能是多个位的组合（如 PermRead | PermWrite）—— 否则逻辑失效。
批量权限校验时，^uint64(0) 比循环更快
当需要「排除某几个权限」或「取反」时，常见做法是遍历所有已知权限位逐个清除，这 O(n) 且易漏。正确方式是直接用位取反：allowed := allPerms &^ forbidden（&^ 是 Go 的 AND-NOT 运算符）。
比如禁止用户拥有删除和审计权限：
const (
PermDelete uint64 = 1
<p>容易踩的坑：</p>
- 误写成
userPerms ^ forbidden（异或 ≠ 清除） - 把
forbidden当作单个位使用，实际它是多位置 1 的掩码 - 在 hot path 中重复计算
forbidden，应预计算为常量或包级变量
为什么不要用 bits.OnesCount64 统计权限数量
统计用户拥有多少种权限看似简单，但 bits.OnesCount64 是调用 runtime 的 POPCNT 指令（x86）或软件回退实现（ARM），在非 x86 平台可能慢 3–5 倍。更糟的是，99% 的权限控制场景根本不需要数量 —— 只需「有/无」判断。
如果真要统计（比如做权限可视化），优先考虑预计算：
- 维护一个全局
[]int查表数组，索引为uint64值，值为 bit 数（仅适用于低频更新、高频查询） - 用
for i := 0; i 手动计数 —— 在 ARM 上比 <code>OnesCount64更稳定，且编译器常能优化为 BSR/CLZ 指令 - 完全避免统计：用
fmt.Sprintf("%064b", perms)调试时看，生产环境别留
真正的极致性能，是让权限判断停留在 CPU 的 ALU 单元里，不触发任何函数调用、不访问内存、不分支跳转 —— 位运算是少数能在 1 个周期内完成的原语，别把它搞复杂了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
