必须用uint64而非int存储权限位，因int在32位系统仅32位，无法容纳64种原子权限，且int64负数右移行为在Go版本间不一致；uint64提供稳定64位无符号空间，右移恒补0、语义确定，避免permission & 1在32位环境高位截断致判false。
Go 语言里用位运算做角色权限控制，不是炫技，而是真能省内存、扛高并发、避免字符串匹配开销。但直接上 & | 很容易踩坑——类型不对、判断逻辑错、多权限组合误用，一跑就漏权限或永远过不了。
为什么必须用 uint64 而不是 int 存权限位
32 位系统下 int 只有 32 位，而实际项目常需支持 64 种以上独立操作（比如 PermRead、PermWrite、PermDelete、PermAudit……一直编到 1 << 63）。用 int 在 32 位环境右移或取反会溢出，permission & 1 可能恒为 0；int64 负数右移行为在 Go 1.20 和 1.21+ 间不一致；uint64 语义确定、无符号、稳定提供 64 位空间。
- 所有权限常量统一声明为
uint64：如const PermRead uint64 = 1 << 0 - 用户权限变量必须是
uint64类型，不能是int、uint（宽度不固定）或int64 - 初始化全权限别写
math.MaxUint64，直接用^uint64(0)——无依赖、零分配、指令级快
HasPerm 函数里为什么用 & 而不是 ==
权限检查本质是「是否包含某子集」，不是「是否完全相等」。userPerms & requiredPerm == requiredPerm 看似严谨，但当 requiredPerm == 0 时恒为 true（任何数 & 0 都是 0），空权限绕过校验；更糟的是它多一次比较，性能不如单次与运算 + 非零判断。
- 正确写法：
func HasPerm(perms, p uint64) bool { return perms & p != 0 } -
p必须是单个权限位（如PermRead），不能是组合值（如PermRead | PermWrite）——否则语义变成「只要含任一权限就放行」，不符合多数业务要求 - 若真需「必须同时具备多个权限」，应拆成多次调用：
HasPerm(u, PermRead) && HasPerm(u, PermWrite)，语义清晰且可短路
批量清除权限时别用 ^ 或循环，用 &^
要禁止用户拥有删除和审计权限，常见错误是写 userPerms = userPerms ^ (PermDelete | PermAudit)（异或 ≠ 清除），或遍历所有已知权限逐个判断再拼掩码——O(n)、易漏、不可维护。
立即学习“go语言免费学习笔记（深入）”；
- 正确方式：
forbidden := PermDelete | PermAudit，然后userSafePerms := userPerms &^ forbidden -
&^是 Go 内置的 AND-NOT 运算符，单指令完成清除，无分支、无循环、无 panic 风险 - 注意：
forbidden是掩码（多位为 1），不是单个位；误当单个位用会导致其他权限也被清掉
权限位定义和使用中三个最易忽略的细节
位运算权限看着简单，但生产环境翻车最多的地方，往往藏在初始化、组合、校验链路的衔接处。
-
iota定义权限时没显式转uint64：如const (PermA uint64 = iota; PermB)没写类型，第二项会推导为int，后续参与运算就溢出 - 把角色当成权限位直接传给
HasPerm：角色是集合概念，应先查出该角色对应的所有权限位，再逐个或批量校验，不能把角色 ID 当作掩码用 - HTTP 中间件注入权限后，在 handler 里用
context.Value取值没判ok：断言失败直接 panic，必须先if perms, ok := ctx.Value(key).(map[string]struct{}); ok { ... }
