byte类型无溢出保护，强制转换是低8位截断再按补码解释，非模运算；应避免误用，优先选int等更安全类型，并用Math.toByteExact等工具主动防御。
Java 中 byte 类型本身不会“自动溢出”——它没有内置的溢出检测或保护机制。所谓“越界后自动变成 -128 或 127”这类现象，其实是强制类型转换时发生的确定性位截断行为，不是语言主动提供的功能，更不是安全可靠的逻辑工具。
你真正要处理的，是如何在业务中正确应对 byte 范围受限（-128 ~ 127）带来的数值失真风险。
明确 byte 溢出的本质是位截断，不是循环
当一个 int 值（如 130、257、-129）被强制转为 byte：
– JVM 不做范围检查；
– 直接取该 int 的低 8 位二进制；
– 再按补码规则重新解释这 8 位，得出最终 byte 值。
例如：
(byte)130 → 130 的二进制低 8 位是 10000010 → 补码解释为 -126
(byte)257 → 257 = 0x0101 → 低 8 位是 00000001 → 结果为 1
这不是模 256 运算，而是硬件级的截断，不可逆、不保序、不保符号。
别让 byte 承担它不该承担的职责
常见误用场景及替代方案：
- 想表示 0~255？→ 用 int 存储，需要无符号语义时写
b & 0xFF - 做索引（如环形缓冲区）？→ 不用 byte 做游标，改用
int cursor+ 位运算：index = cursor & (capacity - 1)（仅当 capacity 是 2 的幂时成立） - 协议解析中读到 0xFF 当作 255？→ 明确它是“无符号字节”，解析时统一转成
int unsigned = b & 0xFF - 把 byte 当状态码或 ID？→ 风险极高，建议直接用 short 或 int，避免隐式收缩
主动防御：让溢出暴露出来，而不是静默丢数据
靠人工记住 -128/127 边界不可靠。应使用 JDK 提供的防御性工具：
立即学习“Java免费学习笔记（深入）”；
- 用 Math.toByteExact(int) 替代
(byte)x：超范围时抛ArithmeticException，立刻中断错误流程 - 关键字段转换前加校验：
if (x Byte.MAX_VALUE) throw ... - 日志中同时记录原始值与转换结果：
log.debug("raw={} → byte={}", raw, (byte)raw)，便于追溯精度丢失路径
网络/IO 场景下特别注意符号和字节序
字节数组与整型互转时，溢出常源于语义错配：
- 协议定义的是无符号 4 字节整数，但用
ByteBuffer.getInt()解析 → 结果可能为负 → 正确做法：((long)buf.getInt()) & 0xFFFFFFFFL - 手动拼 short：
(b1 ，必须对 b2 做 <code>& 0xFF防止符号扩展 - 优先使用 ByteBuffer 而非手写位移：它支持指定字节序、自动越界检查、类型对齐
