byte最小值是-128，因8位补码表示范围为-128~127，其中10000000直接定义为-128，无对应原码；Java编译期检查字面量赋值，但算术运算在运行时按int处理后截断。
为什么 byte 的最小值不是 -127 而是 -128？
因为 Java（以及几乎所有现代计算机系统）用补码表示有符号整数，而 8 位补码能表示的数值个数是 256 个，正负对称分配时，0 占一个位置，剩下 255 个数必须一分为二——但补码的设计让负数多出一个：-128。
关键在于 1000 0000 这个二进制序列：
它不是 -0（原码中 -0 是 1000 0000，但补码下 +0 和 -0 合并为 0000 0000）；
它也不是某个负数的反码加 1 的中间结果；
它是人为约定的、唯一没有对应原码/反码的补码值，直接定义为 -128。
-
1000 0000是byte能存下的最小补码，也是 -128 的“身份证” - 试图用原码规则推导 -128：先写 -128 的原码 → 需要 9 位（符号位 + 128 的 7 位二进制），超出
byte范围，所以不成立 - Java 不允许你手动构造
1000 0000的原码或反码；它只认补码，且只接受这个字节作为 -128
用 Integer.toBinaryString() 看 byte 补码容易误解
直接调用 Integer.toBinaryString((int)b) 会把 byte 符号扩展成 int 再转二进制，导致输出长度不固定、高位全是 1，看不出真实字节内容。
正确做法是屏蔽高 24 位，只留低 8 位：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
立即学习“Java免费学习笔记（深入）”；
byte b = -128;
String s = String.format("%8s", Integer.toBinaryString(b & 0xFF)).replace(' ', '0');
// 输出: 10000000
-
b & 0xFF把byte当作无符号数转成int，避免符号扩展干扰 - 不加这步，
Integer.toBinaryString(-128)输出的是11111111111111111111111110000000（32 位） - 调试时若看到一长串 1 开头的二进制，第一反应应该是“被符号扩展了”，不是
byte本身长这样
赋值越界时编译器报错 vs 运行时溢出
Java 对 byte 字面量赋值做编译期检查，但算术运算全在运行时按 int 处理，再强制截断——这是最常踩的坑。
- 编译错误：
byte b = 128;→ 报错 “possible loss of precision” - 看似合法但实际溢出：
byte b = 127; b++;→ 运行后b == -128，因为 127+1=128，截断低 8 位得1000 0000 - 更隐蔽的：
byte b = (byte)(127 + 1);编译通过，结果仍是 -128；括号没用，加法先升为 int，再强转 - 想安全加 1？得自己判断：
if (b
和 char、short 对比时别套用同一套“符号位逻辑”
char 是无符号 16 位，范围 0~65535；short 是有符号 16 位，范围 -32768~32767。它们都用补码，但“为什么 char 没有负数”这种问题，根源不在补码，而在语言规范定义。
-
char在 Java 中被明确定义为“UTF-16 code unit”，语义上就是非负，编译器禁止赋负值，哪怕你写(char)-1也会被当作无符号解释（65535） -
short和byte同属有符号补码类型，只是位宽不同：-32768 = -215，和 -128 = -27 是同一公式 - 别用“第一位是符号位，所以负数最多 -127”这种原码直觉去猜——那是错的起点；补码下，
1000...000（最高位 1、其余全 0）永远是 -2n-1
