Java里写0b二进制字面量，到底支持哪些版本？
Java 7 开始才支持 0b（或 0B）前缀，低于这个版本直接编译报错：error: illegal start of type。别在 Java 6 项目里试，也别指望 Android API 19 以下能跑——那会儿的 Dalvik 还不认这个语法。
-
0b1010是合法的，值为 10；0B1111_0000也合法（下划线分隔符 Java 7 起同步支持） - 不能写
0b后跟非 0/1 字符，比如0b102报错：error: integer number too large - 负数不能直接写成
0b11111111当作 -1 用——它就是 255；要表示补码需显式强转：(byte) 0b11111111
用0b写位掩码时，为什么&和|结果常出人意料？
问题不在运算符，而在字面量默认类型是 int。比如你写 0b1000_0000，看着像一个字节，实际是 128（正数），不是 -128。跟 byte 变量做 & 时会先提升为 int，高位补 0，结果可能完全偏离预期。
- 想安全提取某一位：用
value & (1 比硬写 <code>0b00001000更清晰、不易错位 - 如果必须用二进制字面量定义掩码，建议显式限定类型：
byte mask = (byte) 0b1000_0000，否则和byte值做位运算会隐式提升 - 检查是否设置了第 3 位（从 0 开始）：写
(flags & 0b00001000) != 0可以，但更推荐(flags & (1 ——可读性高，且避免手数位数数错
和Integer.toBinaryString()混用时，为什么打印出来全是正数？
Integer.toBinaryString() 只输出无符号二进制表示，不带符号位，也不补前导零。你传进去 0b11111111（即 255），它吐出 "11111111"；但如果你本意是表示 byte 的 -1（即 (byte) 0b11111111），再转成 int 传给它，就会得到 "11111111111111111111111111111111"（32 个 1）——因为符号扩展了。
- 要按字节看二进制：先强制截断再补零，比如
String.format("%8s", Integer.toBinaryString(b & 0xFF)).replace(' ', '0') - 调试时别只信
System.out.println(0b1010)输出的十进制值，得用Integer.toBinaryString()配合掩码确认实际位模式 - 日志中想直观显示标志位状态，建议封装一个工具方法，输入
int和位宽（如 8），返回固定长度的二进制字符串
Android 或老 JVM 上遇到0b报错，有没有兼容写法？
没有运行时兼容方案——语法层面不识别就是不识别。唯一办法是退回到十六进制或十进制字面量，靠注释说明位含义。例如：final int FLAG_A = 0x01; // 0b00000001，既兼容又自解释。
立即学习“Java免费学习笔记（深入）”；
- Hex 更紧凑：
0xFF比0b11111111少打 3 个字符，且程序员普遍熟悉 - 真需要动态构造位模式（比如根据配置生成掩码），用
(1 表达最稳妥，JVM 所有版本都支持 - CI 流程里记得检查
sourceCompatibility和targetCompatibility是否设为 1.7+，否则即使写了0b也会在编译阶段失败
位运算本身不难，难的是字面量类型、隐式转换、符号扩展这三者叠加时，哪一步悄悄变了数据。写 0b 图的是直观，但一旦涉及跨类型操作，就得盯紧实际参与运算的值到底是多少位、有没有被提升、符号位怎么走——这些细节，光看二进制写法是看不出来的。
