Java整数均以二进制补码存储，类型转换本质是补码位序列的截断或符号扩展，位运算直接操作补码比特，同一比特模式因解释规则不同可表不同数值。
Java 中所有整数类型（byte、short、int、long）都以二进制补码形式在内存中存储，而不是原码或反码。这种设计不是 Java 特有，而是现代计算机体系的通用约定——它直接决定了类型转换时的底层行为和结果。一旦忽略补码机制，强制类型转换就容易出现“数值突变”甚至符号反转，比如 int a = 200; byte b = (byte) a; 得到的是 -56，而非 200。
补码是 Java 整数的唯一存储形态
无论正负，Java 整数在 JVM 内存中始终以补码表示：
- 正数和零：补码 = 原码 = 二进制表示，高位补 0 至目标位宽（如 int 补满 32 位）
-
负数：先取对应正数的二进制，再逐位取反，最后加 1；例如 -5 的 32 位补码是
11111111 11111111 11111111 11111011 -
0 的唯一性：补码中只有
000...000一种表示，彻底消除原码/反码中 +0 与 -0 并存的问题 -
运算统一性：CPU 加法器对任意两个补码值做加法，结果自然符合数学意义（如
5 + (-5) == 0），无需判断符号
类型转换本质是“截断”或“扩展”补码位序列
Java 的强制类型转换不改变比特内容，只调整参与运算的位数：
-
大→小（如 int → byte）：仅保留低 8 位，高位直接丢弃。若截断后最高位为 1，则新值被解释为负数。例：
int x = 200（补码末 8 位为11001000）→(byte)x就是11001000，按 byte 补码解释为 -56 -
小→大（如 byte → int）：执行符号扩展——复制原值最高位（符号位）填充高位。例：
byte b = -1（补码11111111）→ 转成 int 后变成11111111 11111111 11111111 11111111（即0xffffffff），值仍为 -1 -
关键陷阱：若想把负的 byte 当作无符号数用（如转十六进制），必须先与
0xff按位与——(byteValue & 0xff)把高 24 位清零，得到 0~255 范围内的正值
位运算直接操作补码比特，结果仍按补码解读
Java 所有位运算符（&、|、~、^、移位）均作用于操作数的补码表示：
立即学习“Java免费学习笔记（深入）”；
-
~x（按位取反）不是“求负”，而是翻转全部比特；其结果值由目标类型补码规则决定。如~2（0000...0010→1111...1101）被解释为 int 类型的 -3 - 移位运算也依赖补码：右移
>>是算术右移（带符号扩展），>>>是逻辑右移（高位补 0），两者对负数结果差异显著 - 不同位宽类型混用时，JVM 先将较小类型提升为 int（符号扩展），再运算。例如
byte a = -1, b = 1; int c = a & b;实际计算的是0xffffffff & 0x00000001 == 1
常见误判根源：混淆“比特模式”与“数值含义”
同一个二进制序列，在不同上下文中可代表不同数值，关键在于解释规则：
-
11111111在 byte 中是 -1（8 位补码）；在 int 中若未经扩展，直接当作 int 值就是 255（但 Java 不会这样，默认符号扩展） -
Integer.toBinaryString(-1)输出11111111111111111111111111111111（32 位），但该方法不补前导零，也不显式标出符号位，易误以为“少了位数” - 调试时用
System.out.printf("%08x", b & 0xff)查看 byte 的十六进制，比直接打印b更可靠——后者输出的是补码解释后的十进制，可能误导
