整型选型应注重“合不合适”而非“够不够用”：日常开发统一用int，处理二进制数据用byte，超大整数必须用long并加L后缀，short基本不用除非内存极度受限。
整型选型不是看“够不够用”，而是看“合不合适”。Java 的 byte、short、int、long 各有明确边界和设计意图，乱用轻则隐式转换出错，重则线上溢出、协议解析失败。
日常开发统一用 int
绝大多数场景下，循环变量、数组下标、计数器、ID（非超长）、状态码、配置值等，都该用 int：
- 它是 JVM 最优化的整型，32 位对齐，运算效率高
- 所有整数字面量（如
100、999999）默认就是int类型 - 可读性强，协作成本低，不会让同事疑惑“为什么这里用 short”
- 内存节省收益极小——现代应用中，一个
short节省的 2 字节，在对象头、对齐填充、GC 开销面前几乎可忽略
处理原始二进制数据时用 byte
byte 的存在意义不是“省空间”，而是“语义精准”：
- 网络协议字段（如 TCP 头中的 TTL、校验和）、文件头、图像像素（RGB 各通道 0–255）、串口通信数据——天然对应 1 字节，避免强制截断或符号扩展
- 声明时直接赋字面量（
byte b = -1;），超出范围（如byte b = 128;）编译报错，反而是安全提示 - 别把
byte当“小 int”用：比如存年龄、温度，后续参与加减乘除会自动提升为int，反而多一次类型提升开销
需要超大整数时必须用 long，且带 L 后缀
当数值可能突破 ±21 亿，就必须切换到 long：
立即学习“Java免费学习笔记（深入）”；
- 典型场景：毫秒级时间戳（
System.currentTimeMillis()）、纳秒级计时（System.nanoTime()）、大文件大小（>2GB）、分布式 ID、天文/金融大额累计值 - 字面量必须显式加
L（推荐大写，避免和数字1混淆），例如：long ts = 1727289600000L; - 不加 L 会按
int解析，超过int范围直接编译失败，比如long x = 3000000000;报错
short 基本不用，除非明确内存密集型场景
short 在现代 Java 应用中属于“存在但少用”的类型：
- 取值范围（-32768～32767）尴尬：比
byte大，又远不如int安全；JVM 对它的优化程度不如int - 仅在极少数情况考虑：千万级
short[]数组（如音视频采样缓存）、嵌入式设备内存极度受限、与 C/C++ 接口对齐 - 切忌用
int伪装无符号short（如用int存 0–65535）：Java 没有 unsigned 类型，后续位运算或网络传输极易因符号位扩展出错
