byte溢出本质是低8位截断与补码重解释，非语言功能；它不报错但不可用于环形缓冲区索引，因固定模256且符号翻转，正确做法是用int游标配合capacity为2的幂时的位运算index = cursor & (capacity - 1)。
byte 是 8 位有符号整数，它的最高位（第 7 位，从 0 开始计）就是符号位：0 表示正数或零，1 表示负数。这个符号位不是“独立标签”，而是补码体系中参与运算的真实比特——它既定义正负，也参与加减、扩展、溢出判断全过程。
符号位是数值的一部分，不是装饰
在 byte 中，00000001 是 +1，10000001 不是“-1”，而是 -127（因为补码下，10000001 = -128 + 1）。符号位直接贡献权重：最高位代表 -2⁷ = -128，而非 +128。所以整个 byte 的值是：
- 若符号位为 0：值 = 后 7 位二进制数（0 到 +127）
- 若符号位为 1：值 = -128 + 后 7 位二进制数（-128 到 -1）
为什么正数扩展 byte 到 short 要高位填 0？
把 byte 值 00000101（+5）提升为 16 位 short，必须变成 00000000 00000101。填 0 是因为：
- 填 1 会把 +5 变成 11111111 00000101，解释为补码就是 -251，完全错误
- 补码扩展本质是保持数值不变，而高位加 0 不改变总和（0 × 2¹⁵ = 0）
- CPU 加法器不关心“这是 byte 还是 short”，只认补码；统一填符号位才能跨位宽无缝运算
负数的符号位如何撑起整个负值范围？
byte 最小值 -128 对应 10000000，这不是“-0”，而是精确等于 -2⁷。它的存在说明：
- 符号位 1 搭配全 0 数值位，构成最负的合法值
- -128 没有对应的正数 +128（超出了 7 位能表示的最大正数 127），所以负数比正数多一个
- 所有负数补码都靠符号位“扛住”负权重，再由低位补偿，例如 11111101 = -128 + 125 = -3
溢出时符号位会“翻车”，但翻得有规律
两个正 byte 相加结果超出 +127，比如 127 + 1 → 10000000，符号位从 0 变 1，值变成 -128。这不是错误，而是补码模运算的自然表现：
- 溢出本质是结果对 2⁸ = 256 取模，127 + 1 = 128 ≡ -128 (mod 256)
- 硬件检测溢出：两正数相加得负数，或两负数相加得正数，即符号位“意外反转”
- Java 中 byte 运算自动截断，符号位变化正是溢出信号
