将长度为3的byte数组转为int：为何方案(a)正确而(b)错误？

这问题的核心其实是有符号byte类型的符号扩展在搞鬼，很多刚接触位运算的同学都会踩这个坑！

首先得明确：在Java（以及不少编程语言）里，byte是有符号的8位整数，取值范围是-128到127。当你把一个byte值参与位运算（比如移位、按位或）时，它会先被自动提升为int类型（32位）。这个提升过程会触发符号扩展规则：

• 如果原byte的最高位（符号位）是0（正数），提升为int后高位的24位都填0；
• 如果原byte的最高位是1（负数），提升为int后高位的24位都会被填充为1，而不是0。

代码(a)的正确性 #

array[0] & 0xff这个操作的核心作用，就是把有符号byte强制转换成无符号的8位值：

• 0xff是int类型的0x000000ff，当byte和它做按位与时，即使byte先被提升为int，& 0xff会把高位的24位全部清零，只保留低8位的原始二进制数据——不管原byte是正还是负。
• 之后再做左移操作，得到的就是我们预期的“把这8位二进制放到int对应位置”的结果，不会有多余的1干扰高位。

举个反例：假设array[0] = (byte)0x80（二进制10000000，对应十进制-128）

• array[0] & 0xff的结果是0x00000080（十进制128）
• 左移16位后得到0x00800000，这正是我们想要的把这8位放到int的第24-31位的正确结果。

代码(b)的问题 #

直接对array[0]做左移操作时，会先触发符号扩展，这在byte为负数时就会出问题：

• 还是用array[0] = (byte)0x80的例子，它被提升为int后会变成0xffffff80（因为符号位是1，高位全部填1）
• 左移16位后得到0xff800000，此时这个int的最高位是1，会被解析成负数，完全不符合我们把byte数组作为无符号二进制拼接的预期。

你提到的array[0]是01010101（0x55，正数）的情况，两种代码结果确实一致——因为正数的符号位是0，符号扩展后高位都是0，移位后结果相同。但代码(b)无法处理符号位为1的byte值，所以是不严谨、不正确的写法。

内容的提问来源于stack exchange，提问作者Tirafesi