byte类型的取值范围是 -128 到 127，这一区间看起来有些不对称——负数比正数多了一个。核心原因在于它使用8位二进制并以补码形式存储有符号整数，而8位总共只能表示256种不同的状态。如何合理分配这256种状态，本质上是一个设计上的取舍。

8位二进制仅有256种组合

一个byte占用1字节，即8个比特位，每位只能取0或1。所有可能的排列共有2⁸ = 256种。这256个编码必须全部分配给不同的整数值——既不能浪费，也不能重复。

• 0占用一个编码：0000 0000
• 剩余255个编码需要分配给正数和负数
• 补码的设计使得负数比正数多一个：-128到-1共128个，0一个，+1到+127共127个

补码规定1000 0000就是-128

Java和绝大多数现代系统不再使用原码或反码，而是直接采用补码进行存储和运算。关键点在于：

• 0111 1111是+127的补码（同时也是原码）
• 1000 0000是唯一没有对应原码的补码值——它被直接定义为-128
• 这一约定并非推导而来，而是标准定义：在8位补码中，1000 0000 ≡ -128
• 试图用“先写出-128的原码再转换为补码”的方法会失败，因为-128的绝对值128需要7位（1000 000），加上符号位共需9位，超出了byte的表示范围

为什么不是-127到+127？

如果按原码理解——最高位为符号位，其余7位表示数值，确实会得出±127的错觉。但问题在于：

• 原码中存在+0（0000 0000）和-0（1000 0000）两个零，浪费了一个编码
• 补码将+0和-0统一为0000 0000，从而腾出1000 0000这个编码给-128
• 这样既消除了冗余，也支持加减统一运算（减法可视为加法），硬件实现更加高效

实际编程中需要留意的细节

这个取值范围并非纯理论，它直接影响代码行为——编写代码时稍不留意就会踩坑：

• 字面量赋值越界会导致编译报错：byte b = 128; → 编译失败
• 运行时算术溢出不报错但结果会翻转：byte b = 127; b++; → b 变成 -128
• 打印二进制时注意符号扩展的干扰：使用 b & 0xFF 后再转字符串，才能看到真实的8位二进制表示