选 int 还是 long，核心看数据真实范围：int（±21亿）覆盖多数业务场景，JVM优化好；超范围必须用long，如时间戳、大文件、分布式ID等，且字面量需加L后缀。
选 int 还是 long，核心就一条：看数据真实范围，不靠猜测，也不图省事。
大多数场景直接用 int
int 范围是 -2147483648 到 2147483647（约 ±21 亿），覆盖绝大多数业务需求：
- 用户年龄、商品库存、HTTP 状态码、数组下标、循环变量
- 普通数据库主键（尤其单库单表且 ID 未超 20 亿）
- 状态标识、计数器（如单日 PV 小于 1000 万时完全够用）
JVM 对 int 做了深度优化，运算快、内存占 4 字节、缓存友好，是默认首选。
必须用 long 的硬性场景
只要数据可能超出 int 上限，就必须用 long，否则溢出是静默的——不会报错，但结果错得离谱：
立即学习“Java免费学习笔记（深入）”；
- 时间戳：System.currentTimeMillis() 返回毫秒值，2038 年后 int 就会溢出；Instant.now().toEpochMilli() 也必须接 long
- 文件大小：Files.size() 返回 long，2GB 以上文件（即 > 2147483647 字节）int 无法表示
- 分布式 ID 或分库分表主键：Snowflake、Leaf 等生成的 ID 动辄 10^15 级别，远超 int 范围
- 高精度金额（单位为“分”）：100 万元 = 100000000 分，已接近 int 上限；再加增长空间，long 更稳妥
字面量和赋值细节不能忽略
Java 把无后缀的整数字面量默认当 int 处理。即使你声明的是 long 变量，若字面量本身超出 int 范围，不加 L 就编译失败：
- ✅ 正确：long ts = 1718970345678L;、long id = 0x1F2A3B4C5D6E7F8AL;
- ❌ 错误：long x = 9223372036854775807;（编译报错：integer number too large）
即使数值在 int 范围内，比如 long y = 100;，虽能编译通过（隐式转换），但为保持一致性与可读性，建议涉及时间、ID 等语义明确为 long 的场景，统一加 L 后缀。
别为了“省字节”强行降级，也别为“图安心”盲目升 long
byte/short 看似省内存，但实际使用受限：
- byte 运算自动提升为 int，byte a = 1, b = 2; byte c = a + b; 直接编译失败，需强转
- 百万级数组中，long[] 比 int[] 多占 4MB 内存——不是数字游戏，而是 GC 和 CPU 缓存的真实负担
- 年龄字段用 long 是浪费；HTTP 状态码用 byte 虽可行，但可读性和维护性不如 int
类型选择的本质，是在数据范围、内存效率、JVM 行为和代码可维护性之间找平衡点。
