权限位定义必须用1ULL，因其保证64位无符号类型，避免32位系统左移超界导致的未定义行为，如1<<48在32位int下会出错。
权限位定义必须用 1ULL 避免整型溢出
直接写 1 在 32 位系统或 <code>int 为 32 位的编译器下会触发未定义行为——左移超出了 int 范围，结果可能为 0 或负数。实际项目中常见权限位超过 20 个，一不留神就踩坑。
正确做法是统一用无符号长整型字面量左移：
constexpr uint64_t READ = 1ULL << 0; constexpr uint64_t WRITE = 1ULL << 1; constexpr uint64_t EXEC = 1ULL << 2; constexpr uint64_t DELETE = 1ULL << 35; // 安全，不会溢出
- 所有权限常量必须声明为
uint64_t或更大（如uint128_t，需编译器支持），不能依赖int或unsigned - 避免用宏定义（如
#define READ (1 ），宏不参与类型检查，无法阻止误用 - 如果权限总数预估超 64 个，需改用
std::bitset或std::vector<bool></bool>，但会丢失原子性与位运算效率
has_permission 必须用按位与加非零判断，不能用布尔等值
常见错误写法：return (mask & perm) == perm; —— 这在 perm 是复合权限（如 READ | WRITE）时逻辑正确，但若 perm 是单一位（如 READ），看似等价，实则隐藏风险：当 mask 为 0 时，(0 & READ) == READ 恒为 false，没问题；但一旦有人把 perm 误写成 0 或非法值，比较可能意外通过。
更本质的问题是：权限检查只应确认“某位是否置 1”，不是“子集是否完全匹配”。所以标准做法是：
立即学习“C++免费学习笔记（深入）”；
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
bool has_permission(uint64_t mask, uint64_t perm) {
return (mask & perm) != 0;
}
- 该函数可同时支持单权限（
READ）和多权限组合（READ | WRITE）检查，语义清晰 - 传入 0 时恒返回
false，符合直觉 - 不要用
!!(mask & perm)，虽然结果一样，但可读性差且无必要
权限叠加与清除必须用 |= 和 &= ~，禁用 + / -
用加减法操作位掩码是典型反模式：mask += READ; 看似能“添加”，但如果 READ 已存在，加法不会改变结果，但若误加了重复值（比如两次 += READ），数值上会翻倍，破坏位结构；更糟的是 mask -= READ，当 READ 未设置时，会向下借位，彻底搞乱其他位。
正确的原子操作方式只有两种：
// 添加权限（置位） mask |= READ; // 移除权限（清位） mask &= ~WRITE;
-
~WRITE是安全的，因为WRITE是uint64_t类型，取反后高位自动补 1，仅影响目标位 - 如需批量移除多个权限，写成
mask &= ~(READ | EXEC);，不要分多次&= ~，避免中间态被并发读取 - 若需“仅保留某几个权限”，用
mask = mask & (READ | WRITE);，即显式白名单过滤
调试时打印权限状态别手写循环，用 std::bitset 一行转字符串
开发中常需日志输出当前 mask 值对应哪些权限，手写 64 位遍历易错且冗长。直接借助 std::bitset 可读性强、不易出错：
std::string to_permission_string(uint64_t mask) {
std::bitset<64> bs(mask);
return bs.to_string(); // 返回 64 位二进制字符串，高位在前
}
但注意：这串字符是纯二进制位序（"000...101"），人类难读。更实用的是映射回权限名：
std::vector<std::pair<uint64_t, const char*>> permission_names = {
{READ, "READ"}, {WRITE, "WRITE"}, {EXEC, "EXEC"}, {DELETE, "DELETE"}
};
std::string describe_permissions(uint64_t mask) {
std::string s;
for (const auto& [bit, name] : permission_names) {
if (mask & bit) {
if (!s.empty()) s += "|";
s += name;
}
}
return s.empty() ? "NONE" : s;
}
- 这个
describe_permissions输出类似"READ|WRITE"，适合日志和调试器 watch 表达式 - 务必保证
permission_names中的位顺序与定义顺序一致，否则遍历时可能漏判（虽然逻辑上不影响结果，但可维护性差） - 生产环境避免频繁调用此函数，字符串拼接有开销；调试宏中使用即可
DELETE 还是单独设 DELETE_CHILD，这类决策一旦定错，后续所有 & | ~ 都只是在加固错误假设。 
