java中byte和short的取值范围由位数与有符号补码规则决定：byte为8位，范围−128到127；short为16位，范围−32768到32767；溢出时静默回绕，需通过校验注解、强制转换防护及类型升级主动防范。
Java 基础数据类型取值范围不是凭空记忆的数字，而是由位数和补码规则严格决定的；溢出不会自动报错，但会静默回绕，必须靠主动检查和设计防护来避免逻辑错误。
byte 和 short 的边界怎么算出来的？
关键在“位数 + 有符号补码”：
- byte 是 8 位：最高位为符号位，能表示 2⁸ = 256 个值；负数从 −2⁷ = −128 开始（1000 0000），正数到 2⁷−1 = 127（0111 1111）
- short 是 16 位：同理，负数下限 −2¹⁵ = −32768（1000 0000 0000 0000），上限 2¹⁵−1 = 32767（0111 1111 1111 1111）
- int、long 依此类推：int 是 32 位 → −2³¹ 到 2³¹−1，long 是 64 位 → −2⁶³ 到 2⁶³−1
溢出时到底发生了什么？
Java 不做运行时溢出检查，只保留低 N 位并按补码重新解释：
- byte b = 127; b++ → 得到 −128（0111 1111 + 1 = 1000 0000）
- short s = 32767; s++ → 得到 −32768（0x7FFF + 1 = 0x8000）
- (byte)200 → 200 的低 8 位是 1100 1000，符号位为 1，解释为 −56
- 编译期字面量越界（如 short s = 32768;）直接报错，但运行时强制转换或算术运算会静默截断
日常开发中怎么防溢出？
不能依赖语言报错，得自己加防线：
- 配置读取时用校验注解：
@Min(-32768) @Max(32767)配合 Hibernate Validator - 网络/文件读取 byte 数据前，先用 int 接收再判断：
if (raw > 127 || raw - 做加减运算前升位处理：
int result = (a & 0xFF) + (b & 0xFF)（尤其用于 byte 累加） - 关键逻辑后加断言：
if (s Short.MAX_VALUE) throw ...
什么时候该换更大类型？
别硬扛，该升级就升级：
- 算术密集场景（如计数器、坐标计算）优先用 int，避免 short 自动提升带来的隐式转换开销
- JSON 序列化中 short 常被当成 int 处理，容易引发前后端类型不一致
- 金额、精度敏感场景不用整型，改用
BigDecimal - 真需要大范围时，int 不够就上 long，而不是靠
(short)(x % 65536)掩盖问题
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
