用 & 判断状态位交集是否为空：若 a & b != 0，说明至少有一个共同置位；状态常量须为互不重叠的 2 的幂，推荐使用 uint32/uint64 避免符号扩展问题。
用 & 运算判断状态位交集是否为空
多个状态位的“交集是否存在”，本质是看它们是否有任意一个共同置位的比特位。直接用按位与 & 最快：只要 a & b != 0，就说明至少有一个位同时为 1。
常见错误是写成 (a & b) == true 或误用 || 拼接多个标志——布尔逻辑不等价于位交集。
-
STATUS_READ、STATUS_WRITE、STATUS_EXEC应定义为互不重叠的 2 的幂（如1 、<code>1 、<code>1 ） - 若状态变量
flags是整型，判定它是否同时包含读和写权限：if ((flags & (STATUS_READ | STATUS_WRITE)) == (STATUS_READ | STATUS_WRITE)) - 只关心“有没有交集”（不要求全匹配），就用
if (flags & mask)，其中mask是你要检测的一组位（如STATUS_READ | STATUS_EXEC）
避免 | 和 || 混用导致逻辑错乱
组合多个状态时，必须用按位或 | 合并标志；若误用逻辑或 ||，表达式会退化为布尔值（0 或 1），彻底丢失位信息。
例如：if (flags || STATUS_READ) 永远为真（除非 flags == 0），而 if (flags | STATUS_READ) 总是非零——两者都完全没做交集判断。
- 正确拼接多个待查状态：
int need = STATUS_READ | STATUS_WRITE | STATUS_LOCKED - 正确检测：
if (flags & need)→ 有任意一个满足即为真 - 错误写法：
if (flags & STATUS_READ || flags & STATUS_WRITE)虽然结果对，但多了一次运算、可读性差，且无法扩展到动态掩码
注意符号扩展与整型宽度对 & 结果的影响
在 C/C++ 或 Rust 中，如果状态变量是有符号类型（如 int），而你用高位掩码（如 1 ）参与运算，可能因符号位引发未定义行为或意外截断；在 Go 中 <code>int 宽度不固定，更需显式使用 uint32 或 uint64。
- 推荐统一用无符号类型存储状态位：
uint32 flags、const STATUS_X uint32 = 1 - 跨平台时避免依赖
sizeof(int)，直接用uint64覆盖 64 个状态位已足够大多数场景 - JavaScript 中虽无符号类型，但
&默认按 32 位有符号整数处理，超 31 位需用>> 0或BigInt配合&n（ES2020+）
用 __builtin_popcount 或 bits.OnesCount 统计交集位数（进阶需求）
有时不止要“有没有交集”，还要知道“几个位重合”。这时候不能只靠 &，得再统计结果中 1 的个数。
- C/C++：用
__builtin_popcount(a & b)（GCC/Clang），返回交集中置位数量 - Go：导入
math/bits，调用bits.OnesCount(uint64(a & b)) - Rust：用
(a & b).count_ones()（u32/u64自带方法） - 注意：这些函数对 0 输入返回 0，正好对应“无交集”；但别忘了先做
&，再统计，顺序不能反
位运算本身极快，但真正容易出问题的地方，往往不是 & 写错了，而是状态常量定义重叠、类型隐式转换截断、或把掩码当成布尔值反复取反。动手前先确认所有 STATUS_* 是 2 的幂且不重复，比后期调试省十倍力气。
