java 的 byte 类型是有符号的 8 位整数，当参与算术运算时会自动提升为 int 并进行符号扩展，导致高位填充 1（而非 0），这是将字节数组解析为整数时出现意外结果的根本原因。
在 Java 中，byte 的取值范围是 -128 到 127（即有符号 8 位补码），因此十六进制 0x95（十进制 149）超出了正数上限，实际被解释为 -107（0x95 = 1001 0101₂ → 符号位为 1，补码表示 -107）。当你执行如下代码：
int number = bytes[0] + (bytes[1] << 8) + (bytes[2] << 16) + (bytes[3] << 24);
Java 会先将每个 byte 提升为 int（32 位）——而这个提升是有符号扩展（sign extension）：
- bytes[0] == (byte)0x95 → 提升为 int 后变为 0xffffff95（即 -107）
- bytes[1] == (byte)0x19 → 提升为 0x00000019（即 25）
- bytes[2] == (byte)0x07 → 提升为 0x00000007
- bytes[3] == (byte)0x00 → 提升为 0x00000000
于是计算过程实际为：
0xffffff95 // -107 + 0x00001900 // 25 << 8 = 6400 + 0x00070000 // 7 << 16 = 458752 + 0x00000000 = 0x00071895 // 十进制 465045 —— 比预期的 0x00071995 少了 256
为什么少了 256？因为 0xffffff95 相比于无符号解释的 0x00000095，低 8 位相同，但高 24 位全为 1，等价于 -256 + 0x95。因此它在加法中额外引入了 -256，恰好抵消了 bytes[1] << 8 的最低有效字节贡献（25 × 256 = 6400），使结果整体减去 256。
立即学习“Java免费学习笔记（深入）”；
✅ 正确做法：强制零扩展（zero-extension）
使用 (b & 0xFF) 将 byte 转为无符号 int（保留低 8 位，高位清零）：
int number = (bytes[0] & 0xFF)
+ ((bytes[1] & 0xFF) << 8)
+ ((bytes[2] & 0xFF) << 16)
+ ((bytes[3] & 0xFF) << 24);
// 结果：0x00071995 → 465301? 更简洁、健壮的替代方案（推荐）：
使用 java.nio.ByteBuffer（自动处理字节序，默认大端）：
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
byte[] bytes = {(byte)0x95, (byte)0x19, (byte)0x07, (byte)0x00};
int number = ByteBuffer.wrap(bytes).order(ByteOrder.LITTLE_ENDIAN).getInt();
// 注意：上述字节数组按小端序排列，若原意是小端（LSB 在前），则需指定 LITTLE_ENDIAN；
// 若为大端（MSB 在前，即 0x95 是最高字节），则用 ByteOrder.BIG_ENDIAN 或省略（默认）⚠️ 关键注意事项：
- Java 没有无符号基本类型（byte/short/int/long 全为有符号），所有“无符号操作”必须显式通过位掩码（如 & 0xFF）实现零扩展；
- 位移操作符 << 本身无符号/有符号之分，但操作数的符号性会影响其原始值；
- 在网络协议、文件格式或硬件通信中解析二进制数据时，务必确认字节序（endianness）和符号约定，避免跨平台歧义。
总结：理解 Java 的有符号字节 + 自动类型提升 + 符号扩展三者联动机制，是正确进行底层二进制解析的基础。一次 & 0xFF 不仅修复结果，更揭示了类型语义与硬件表示之间的关键鸿沟。
