本文深入解析 java 中 `byte` 类型的有符号特性如何导致字节数组转 `int` 时出现意外结果，并提供安全、可移植的位运算转换方案。
在 Java 中，byte 是有符号的 8 位整数类型，取值范围为 -128 到 127（即 0x80 至 0x7F）。这意味着十六进制字面量 0x95（十进制 149）无法直接以正数形式存储于 byte 中——它会被截断并解释为补码表示的负数：0x95 的二进制是 1001 0101，最高位（符号位）为 1，因此其 byte 值为 -107（即 0x95 - 0x100 = -107）。
当该 byte 参与算术运算（如 + 或 <<）时，Java 会自动将其提升（promotion）为 int。但关键在于：这种提升是符号扩展（sign extension），而非零扩展（zero extension）。也就是说：
- bytes[0] = (byte)0x95 → 实际值为 -107
- 在表达式 bytes[0] + (bytes[1] << 8) + ... 中，bytes[0] 被提升为 int：0xFFFFFF95（即 -107 的 32 位补码）
- 而你期望的是无符号解释下的 0x00000095（即 149）
因此，原计算：
int number = bytes[0] + (bytes[1] << 8) + (bytes[2] << 16) + (bytes[3] << 24); // bytes[0] 提升为 0xFFFFFF95 (-107) // bytes[1] << 8 → 0x1900 (640) // 所以 -107 + 640 = 533 → 0x00000215，再加后续项后累积偏差，最终得 0x00071895（比预期 0x00071995 少 0x100 = 256）
✅ 正确做法：使用 & 0xFF 强制零扩展，消除符号位影响：
立即学习“Java免费学习笔记（深入）”；
byte[] bytes = new byte[4];
bytes[0] = (byte)0x95; // -107
bytes[1] = (byte)0x19;
bytes[2] = (byte)0x07;
bytes[3] = (byte)0x00;
int number =
(bytes[0] & 0xFF) | // → 0x00000095
((bytes[1] & 0xFF) << 8) | // → 0x00001900
((bytes[2] & 0xFF) << 16) | // → 0x00070000
((bytes[3] & 0xFF) << 24); // → 0x00000000
// 结果：0x00071995 ✅? 技巧说明：bytes[i] & 0xFF 中，0xFF 是 int 类型（即 0x000000FF），byte 会先被提升为 int（仍为符号扩展），但按位与操作会将高 24 位清零，只保留低 8 位有效值，等效于无符号转换。
⚠️ 注意事项：
- 不要依赖 (int)bytes[i] —— 这仍是符号转换；
- 若需处理大端序（Big-Endian）字节数组（如网络字节序），应调整位移顺序：bytes[0] << 24 | bytes[1] << 16 | ...；
- 对于更健壮、跨平台的实现，推荐使用 ByteBuffer（注意字节序设置）：
int number = ByteBuffer.wrap(bytes).order(ByteOrder.LITTLE_ENDIAN).getInt();
总结：Java 的 byte 有符号性是设计使然，不是 Bug；理解「提升时的符号扩展」与「手动零扩展（& 0xFF）」的区别，是正确进行底层字节操作的核心前提。
