Java中byte溢出不抛异常而是静默回绕，因8位补码机制导致127+1=-128、-128-1=127；需主动校验范围而非依赖隐式转换，推荐用工具类严格转换并配合单元测试与日志追踪。
Java 中 byte 类型溢出不会抛异常，但结果会静默回绕——比如 127 + 1 变成 -128，-128 - 1 变成 127。这不是 bug，而是补码规则下的确定行为。关键在于：**你得知道它会发生，并主动管住它，而不是等它悄悄破坏逻辑。**
理解溢出本质：8位 + 补码 = 固定循环
byte 是 8 位有符号整数，共能表示 256 个值。补码规定：
- 0000 0000 到 0111 1111 → 0 到 +127（128 个非负数）
- 1000 0000 到 1111 1111 → -128 到 -1（128 个负数）
所以 1000 0000 就是 -128，不是 -0；没有“多一个正数”的空间。所有运算都只保留低 8 位，高位直接丢弃，再按补码重新解释。这就是为什么 (byte)200 得到的是 -56（200 的二进制低 8 位是 1100 1000，符号位为 1，补码值即 -56）。
避免隐式转换导致的静默错误
强制类型转换如 (byte)130 或 (byte)someInt 是最危险的源头——编译器不报错，运行时也不提醒，但数据已经失真。
立即学习“Java免费学习笔记（深入）”；
- 禁止裸写
byte b = (byte)input;，无论 input 是 int、long 还是字符串解析结果 - 统一走校验方法：先判断范围，再转。例如：
if (val < Byte.MIN_VALUE || val > Byte.MAX_VALUE) { throw new IllegalArgumentException("超出byte范围: " + val); } - 对字符串输入，别用
Byte.parseByte()（它遇到超限直接抛 NumberFormatException），改用Integer.parseInt()后再校验，更可控
在运算和协议解析中守住边界
网络通信、文件读取、设备指令等场景，字节流常含原始数值，极易踩坑。
- 做加减运算前，把 byte 提升为 int 或 long 计算，避免中间截断；结果若需存回 byte，必须显式校验后再转
- 用 ByteBuffer 解析多字节整数时，注意字节序和符号性。例如协议定义无符号 byte（0～255），但 Java byte 是有符号的，打印时可用
String.format("0x%02X", b & 0xFF)查看原始值 - 手动拼接 short/int 时，所有中间变量用 int 或 long，别用 byte 累加器——byte + byte 会自动提升为 int，但再强转回去就可能丢数据
用工具和习惯加固防线
靠人盯不如靠机制。
- DTO 层加自定义注解 @ValidByteRange，配合 Spring 校验拦截非法入参，返回 400
- 封装工具类
ByteUtils.toByteStrict(int value)，内部完成范围检查 + 转换，全项目统一调用 - 单元测试覆盖边界值：-129、-128、127、128，验证是否按预期拒绝或回绕
- 日志中记录原始输入和转换后值，便于出问题时快速定位是上游传错，还是本层处理失当
