Java中byte数组与int互转时为何需要使用&0xFF操作？

这个问题问得特别切中要害！其实核心原因完全和Java里byte的有符号特性绑定在一起，咱们一步步拆解就能明白：

先搞懂Java的byte是什么 #

Java里的byte是8位有符号整数，用补码存储，范围是-128到127。这意味着：

• 当一个byte的二进制最高位是1时，它表示的是负数（比如0xFF对应的十进制是-1，而不是我们直觉里的无符号值255）。
• 当把byte类型提升为int类型时，Java会自动做符号扩展：把byte最高位的符号位，填充到int的所有高位（也就是把8位的补码扩展成32位的补码）。比如byte的0xFF（-1）转成int后，会变成0xFFFFFFFF（还是-1），而不是我们想要的0x000000FF（255）。

&0xFF到底在干嘛？ #

0xFF是int类型的常量，二进制是00000000 00000000 00000000 11111111。当我们对一个byte执行byte & 0xFF时：

1. 首先byte会被自动提升为int（触发符号扩展）；
2. 然后和0xFF做按位与操作——这会把int中高24位的符号扩展位全部清零，只保留低8位的原始字节数值；
3. 最终得到的就是这个byte对应的无符号8位整数的int表示（比如byte的0xFF经过&0xFF后，就变成了255，也就是0x000000FF）。

结合代码看具体作用 #

1. unsignedByteToInt方法

假设我们有一个byte数组中的元素是0xFF（也就是-1），如果不做&0xFF处理：

• 直接转成int会变成0xFFFFFFFF，左移16位后会得到0xFFFF0000；
• 这会导致最终组合出来的int值被高位的1污染，完全偏离我们想要的“把4个无符号字节拼接成32位整数”的目标。

而加了&0xFF之后：

• bytes[1] & 0xFF会得到0x000000FF，左移16位后是0x00FF0000，和其他位按位或后，就能正确还原出原始的32位整数。

2. intToUnsignedByte方法

当我们把一个负数int转成byte数组时（比如示例中的0xfffefdfc，这是一个负数），用>>做算术右移会填充符号位，导致右移后的结果高24位都是1。

• 如果直接(byte)(value >> 24)，虽然截断低8位后结果也是0xFF，但&0xFF的作用是明确只保留低8位数值，让代码逻辑更清晰严谨，也能避免一些特殊场景下的符号扩展问题，养成良好的编码习惯。

看示例代码的运行结果 #

示例中int value = 0xfffefdfc，转成byte数组后得到的是0xFF, 0xFE, 0xFD, 0xFC，再转回int又能得到0xfffefdfc，整个过程没有数据丢失，全靠&0xFF帮我们处理了有符号和无符号之间的转换问题。

备注：内容来源于stack exchange，提问作者Lavin Li