Java中short的取值范围是-32768到32767，因其采用16位有符号补码表示：最大值为2¹⁵−1=32767（0x7FFF），最小值为−2¹⁵=−32768（0x8000），共65536个编码空间。
Java 中 short 的取值范围是 -32768 到 32767，这个边界不是凭经验记住的，而是由其 16 位有符号补码表示方式决定的。掌握它，关键在于理解底层机制，并在编码和配置中主动设防。
为什么是 -32768 到 32767？
short 占用 2 字节（16 位），最高位为符号位。用补码表示时：
- 最大正数是 0x7FFF（二进制 0111 1111 1111 1111），即 2¹⁵ − 1 = 32767
- 最小负数是 0x8000（二进制 1000 0000 0000 0000），即 −2¹⁵ = −32768
- 整个空间共 2¹⁶ = 65536 个值，均匀映射到该区间
编译期 vs 运行期溢出行为要分清
Java 对 short 溢出的处理分两种场景：
- 字面量直接赋值（如
short s = 32768;）→ 编译失败，报错“incompatible types” - 运行时计算或强制转换（如
(short)32768或short s = 32767; s++;）→ 不抛异常，直接回绕：32768 → -32768，-32769 → 32767
配置参数防溢出的实操建议
当 short 用于配置项（如 Spring Boot 的 @Value、YAML 数值绑定），字符串转 short 可能静默失败或抛 NumberFormatException。预防方法包括：
立即学习“Java免费学习笔记（深入）”；
- 在配置校验层使用
@Min(-32768) @Max(32767)注解（配合 Hibernate Validator） - 自定义
Converter<String, Short>，对超出范围的输入明确拒绝并提示 - 读取后立即做边界断言：
if (value Short.MAX_VALUE) throw new IllegalArgumentException(...);
替代方案与设计提醒
除非内存敏感（如大规模数组、网络协议字段），否则不建议默认选用 short：
- 算术运算中常自动提升为 int，反而增加隐式转换成本
- JSON 序列化（如 Jackson）默认把 short 当作 int 处理，易引发类型误解
- 真正需要宽范围时，优先考虑 int；超大数才升级 long，而非靠强制转换掩盖问题
