位掩码用 &、|、^ 是因状态少、读写频、内存敏时更省空间且更快；int 存32开关，long 存64，CPU位操作原子、无对象头与GC压力。
位掩码的底层逻辑：为什么用 &、|、^ 而不是布尔数组
因为状态数少、读写高频、内存敏感时，位掩码比 boolean[] 或 EnumSet 更省空间且更快。一个 int 能存 32 个开关，long 存 64 个，CPU 对单个整数的位操作是原子级指令，没有对象头开销，也没有 GC 压力。
常见错误现象：if (flags == FLAG_A | FLAG_B) 写成等号加按位或，实际执行的是赋值+比较混合，结果永远为 true（除非 FLAG_A | FLAG_B 恰好等于 flags）；正确写法是 (flags & FLAG_A) != 0。
- 状态定义必须是 2 的幂：
public static final int FLAG_READ = 1 、<code>FLAG_WRITE = 1 、<code>FLAG_EXEC = 1 - 不要手写
1、2、4、8——易错且不可维护，一律用1 - 避免用
byte或short当掩码类型：Java 位运算会自动提升为int，反而引发隐式截断风险
设置/清除/判断状态的三组标准写法
别靠记忆写错优先级。& 和 | 优先级低于 ==，所以判断必须加括号；清除状态不是减法，而是与反码相与。
典型误用：flags = flags & ~FLAG_READ; 写成 flags = flags - FLAG_READ;——当 FLAG_READ 未设置时，减法会意外关闭其他位。
立即学习“Java免费学习笔记（深入）”；
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
- 判断是否启用：
(flags & FLAG_READ) != 0 - 启用某状态：
flags |= FLAG_READ; - 关闭某状态：
flags &= ~FLAG_READ; - 切换某状态：
flags ^= FLAG_READ; - 同时启用多个：
flags |= FLAG_READ | FLAG_WRITE;
Java 8+ 中 EnumSet 和位掩码的取舍
EnumSet 内部其实也是位掩码实现，但封装了类型安全和迭代能力；它适合状态枚举固定、需遍历或传参场景；裸位掩码适合性能关键路径、序列化体积敏感、或状态动态组合（比如权限码由配置生成）。
兼容性影响：自定义位掩码可直接存进数据库整型字段或网络协议包；EnumSet 序列化后是对象结构，跨语言互通成本高。
- 用
EnumSet：需要for (Permission p : perms)遍历，或方法签名要明确接受EnumSet<permission></permission> - 用裸
int掩码：RPC 接口字段、Redis 位图操作、JNI 交互、AndroidParcelable中压缩存储 - 别混用：不要把
EnumSet.of(A, B)的hashCode()当作掩码值用——它不等于A.bitValue() | B.bitValue()
调试时怎么看懂一串数字代表哪些状态
线上日志里打印出 flags = 19，人眼没法直接对应到 READ|WRITE|EXEC。别靠心算，用工具思维处理。
容易踩的坑：有人写 Integer.toBinaryString(19) 得到 "10011"，但没对齐位宽，看不出第 0、1、4 位被置 1；更糟的是直接查 19 == FLAG_A + FLAG_B + FLAG_C —— 加法在位掩码里无意义。
- 写个临时解析方法：
System.out.println(Integer.toBinaryString(flags | 0x10000).substring(1));补前导零再截取，保证至少 16 位对齐 - IDE 调试时，在变量视图右键 → “View as” → “Binary”（IntelliJ 支持），比手算快十倍
- 单元测试里断言状态组合，别断言原始数字：
assertThat(flags).hasFlags(FLAG_READ, FLAG_WRITE);（可用 AssertJ 的hasFlags扩展）
最麻烦的其实是位域重叠——比如两个不同模块各自定义了 FLAG_RETRY = 1，合并时冲突。这种问题不会报错，只会在某个状态永远无法生效，得靠设计阶段约定命名空间或拆分成不同整型字段。
