必须用 uint64 存权限位，因 int 在 32 位系统仅 32 位易溢出，int64 右移行为不一致，uint64 无符号右移恒补 0；权限检查用 & 而非 ==，因需判断位包含而非相等；禁用权限须用 &^ 而非 ^；文件权限必须写八进制字面量如 0644。
为什么必须用 uint64 而不是 int 存权限位
在 32 位系统上，int 只有 32 位，而现代微服务常需支持 64 种以上原子权限（如 user:read、order:write、audit:export），int 直接溢出。更危险的是：int64 对负数做右移（>>）时，Go 各版本行为不一致；uint64 无符号，右移恒补 0，语义确定。
常见错误：permission & 1 在 32 位环境可能永远为 0——因为高位被截断，导致权限永远判 false。实操建议：
- 所有权限常量声明为
uint64：例如const PermRead uint64 = 1 - 用户权限变量类型固定为
uint64，不写uint（宽度依赖平台） - 初始化全权限用
^uint64(0)，而非math.MaxUint64（前者编译期常量，零开销）
HasPerm 函数里为什么用 & 而不是 ==
权限检查本质是「是否包含某权限位」，不是「是否完全相等」。userPerms & requiredPerm == requiredPerm 看似严谨，但当 requiredPerm 是 0（空权限）时，该表达式恒为 true，导致绕过校验。
正确且高效的做法是：userPerms & requiredPerm != 0。它只做一次与运算加非零判断，性能最优，语义清晰：只要对应位被置 1 就返回 true。
注意前提：requiredPerm 必须是单个权限位（如 PermRead），不能是组合值（如 PermRead | PermWrite）——否则逻辑失效，应改用 HasAllPerms 单独实现。
批量禁用权限时别用 ^，要用 &^
想从用户权限中剔除「删除」和「审计」两个权限，常见误写：userPerms ^ (PermDelete | PermAudit)。这是异或，会翻转对应位，而不是清除——若用户原本没这些权限，反而被意外打开。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
正确方式是 Go 提供的 AND-NOT 运算符 &^：
forbidden := PermDelete | PermAudit userSafePerms := userPerms &^ forbidden // 单指令清除，无分支、无循环
关键点：forbidden 必须是多位置 1 的掩码，不是单个位；不要手写循环遍历每个权限位去清零——O(n) 且易漏。
文件权限操作中 0644 和 644 完全不同
os.Chmod 传入的权限值必须是八进制字面量。漏写前导 0 是最常见错误：0644 是八进制（对应 Unix 权限 rw-r--r--），而 644 是十进制，会被解释为八进制 1204，结果不可控甚至破坏性。
跨平台尤其要注意：
- Windows 下
os.Chmod几乎只影响只读标志，0755中的x位无效 - 不能靠
fi.Mode().Perm() & 0020 != 0判断组写权限——Windows 上永远为false - 敏感文件（如密钥）必须一步到位：
os.WriteFile("key.pem", data, 0600)，避免时间窗口泄露
真正起效的权限控制必须落在应用层，比如路径白名单、JWT 校验；文件系统权限只是辅助手段，且极易因进制写错或平台差异失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
