java 中 `byte` 是有符号类型，直接参与算术运算会触发符号扩展，导致高位字节被错误解释为负数，从而产生意外结果；正确做法是先零扩展（如 `& 0xff`）再移位组合。
在 Java 中将 4 字节 byte[] 转换为 int 时，一个常见却极易出错的做法是直接使用位移加法：
byte[] bytes = new byte[4]; bytes[0] = (byte) 0x95; // 实际值：-107（因 byte 为有符号 8 位） bytes[1] = (byte) 0x19; bytes[2] = (byte) 0x07; bytes[3] = (byte) 0x00; int number = bytes[0] + (bytes[1] << 8) + (bytes[2] << 16) + (bytes[3] << 24); // ❌ 错误结果：0x00071895（而非预期的 0x00071995）
问题根源在于 byte 的符号扩展机制：
Java 的 byte 类型范围是 -128 ~ +127，0x95（十进制 149）超出该范围，强制转换后变为 -107（即 0x95 的补码解释）。当该 byte 参与算术运算（如 + 或 <<）时，JVM 会将其自动提升为 int，但采用的是符号扩展（sign extension） —— 即用最高位（符号位）填充高 24 位：
- (byte)0x95 → 值为 -107
- 提升为 int 后 → 0xFFFFFF95（即 -107 的 32 位补码表示）
因此：
bytes[0] // = -107 → 0xFFFFFF95 (bytes[1] << 8) // = 0x1900 (bytes[2] << 16) // = 0x070000 (bytes[3] << 24) // = 0x00000000
求和时：0xFFFFFF95 + 0x1900 + 0x070000 = 0x00071895（注意 0xFFFFFF95 相当于 -0x6B，减去了 107，导致低字节区域少加了 107，进而影响进位到 0x19 所在的字节——实际表现为 0x19 变成了 0x18）。
✅ 正确解法：零扩展（zero-extension）
通过 & 0xFF 将 byte 转为无符号等效 int（即丢弃符号含义，仅取低 8 位），再进行位移：
int number = (bytes[0] & 0xFF)
+ ((bytes[1] & 0xFF) << 8)
+ ((bytes[2] & 0xFF) << 16)
+ ((bytes[3] & 0xFF) << 24);
// ✅ 正确结果：0x00071995（即 465,301）? 提示：& 0xFF 的本质是强制截断高 24 位，保留原始字节的二进制值（0x95 保持为 0x00000095），避免符号污染。
? 其他安全替代方案：
立即学习“Java免费学习笔记（深入）”；
- 使用 java.nio.ByteBuffer（推荐用于生产环境）：
int number = ByteBuffer.wrap(bytes).order(ByteOrder.LITTLE_ENDIAN).getInt();
- 使用 java.lang.Integer 的静态方法（需注意字节序）：
// 大端序（network order）转 int int number = ((bytes[0] & 0xFF) << 24) | ((bytes[1] & 0xFF) << 16) | ((bytes[2] & 0xFF) << 8) | (bytes[3] & 0xFF);
⚠️ 注意事项：
- 明确字节序（Little-Endian 还是 Big-Endian）：上述示例按小端序（bytes[0] 为最低有效字节）处理；
- 若涉及网络或跨平台数据，务必统一约定并显式指定字节序；
- 对于 long 等更宽类型，同样需对每个 byte 执行 & 0xFF，或改用 ByteBuffer 避免手动计算。
总结：Java 没有无符号基础类型，byte 的“有符号性”在隐式类型提升中悄然改变语义。理解 符号扩展 vs 零扩展 的差异，是写出健壮二进制解析代码的关键第一步。
