byte 和 bit 的基本关系：1 个 byte 永远等于 8 个 bit
Java 中的 byte 是最小的有符号整数类型，占 1 个字节（8 位），取值范围是 -128 到 127。它和 bit 不是“可互相转换”的两种数据类型，而是“包含关系”——bit 是二进制位，是信息的最小单位；byte 是内存中最小的寻址单位，由 8 个 bit 组成。
所以你不会写 byte b = toBit(5); 这种代码，也不会调用什么“转换函数”。所谓“转换”，实际是手动拆解或组合这 8 个 bit。
- 想获取某个
byte的某一位？用位运算：b & (1 （n 从 0 开始，表示最低位） - 想把 8 个
boolean压进 1 个byte？逐位设置：result |= flag[i] ? (1 - 别误以为
Integer.toBinaryString(b)返回的是“8 位补码”——它默认不补零，负数还显示带符号的二进制（比如-1输出"11111111"是错觉，实际输出是"11111111111111111111111111111111"）
用 ByteBuffer 或 BitSet 处理多字节/多位逻辑时的常见误区
当你要处理超过 1 字节的位操作（比如解析网络协议头、读取 packed boolean 数组），直接手撸位运算是可行的，但容易出错。这时候该选 ByteBuffer 还是 BitSet？关键看场景：
-
ByteBuffer：适合按字节边界读写，再配合get()/put()+ 位掩码提取内部 bit。例如解析 TCP 标志位（URG/ACK/PSH/RST/SYN/FIN 共 6 位）：先buf.get(12)拿到 flags 字节，再& 0b00111111屏蔽高两位 -
BitSet：适合随机访问大量 bit（比如布隆过滤器、稀疏标记），但它不对应原始字节数组——BitSet.toByteArray()返回的数组长度不是“总 bit 数 / 8”，而是按需分配，末尾可能补零字节；反过来，BitSet.valueOf(byte[])会把每个byte当作 8 个 bit 逆序加载（即byte[0]的最低位变成BitSet.get(0)） - 别在循环里反复调用
BitSet.get(i)做高频判断——它比数组查boolean[]慢一个数量级；真要性能敏感，老老实实用byte[]+ 位运算
序列化/IO 场景下：bit 级精度丢失的典型表现
Java 所有 IO 类（InputStream、FileChannel、DataOutputStream）都以 byte 为单位读写。如果你试图“写入 3 个 bit”，JVM 实际必须写满 1 个 byte——剩下的 5 位要么填 0，要么继承上次写入的脏数据，取决于缓冲区状态。
立即学习“Java免费学习笔记（深入）”；
- 用
DataOutputStream.writeByte()写0b00000101，文件里就是 1 字节0x05；但你想只写低 3 位（0b101），就必须自己缓存，凑够 8 位再 flush - JSON / XML / 日志打印等文本格式天然不支持 bit 级存储——
byte会被转成十进制或十六进制字符串，bit信息彻底消失 - 某些硬件协议要求字段跨字节对齐（比如第 7~10 位属于同一个标志），这时不能依赖
ByteBuffer.order()，必须手算偏移：int pos = byteIndex * 8 + bitOffset;，再用byteArray[pos / 8]和掩码提取
为什么 byte 不能直接当 bit 数组用？
因为 Java 没有原生 bit 类型，也没有 bit[]。所有“位数组”本质都是 byte[] 或 long[] 加上位运算模拟出来的。这意味着：
- 你声明
byte b = 5;，内存里存的就是0b00000101，但你不能写b[2]去取第三位——byte是标量，不是容器 - 想实现
BitArray.get(int i)，内部必须做除法和取模：byteIndex = i / 8; bitInByte = i % 8;，再执行(data[byteIndex] >> bitInByte) & 1 - 很多开源库（如
fastutil的BooleanArrayList）底层也用long[]存 bit，因为 64 位一次操作比 8 位更高效；但这也意味着size()为 10 的 bit 集合，仍会占用 8 字节内存
真正容易被忽略的点是：位操作的边界检查永远得自己做。Java 不会在 b >> 10 时抛 IndexOutOfBoundsException，它只会默默返回 0（右移超出位宽时补符号位/零）。这种静默行为，在解析二进制协议时最容易埋下 bug。
