Java中long类型的取值范围是-9223372036854775808到9223372036854775807，即-2⁶³至2⁶³−1，为64位有符号整数，可通过Long.MIN_VALUE和Long.MAX_VALUE获取。
Java 中 long 类型的取值范围是 -9,223,372,036,854,775,808 到 9,223,372,036,854,775,807，即 -263 至 263−1，共 64 位有符号整数。这个范围远超 int（仅 ±21 亿），是系统设计中处理“大数”问题的关键基础。
long 的数值边界与安全表示
直接写数字字面量时，超出 int 范围的值必须加 L 后缀（如 123456789012345L），否则编译失败。推荐用大写 L，避免与数字 1 混淆。
- 获取精确极值：用
Long.MIN_VALUE和Long.MAX_VALUE，不依赖硬编码，可读且可移植 - 运行时检查溢出：Java 8+ 提供
Math.addExact()、Math.multiplyExact()等方法，抛出ArithmeticException而非静默截断 - 注意乘法陷阱：两个接近
MAX_VALUE的 long 相乘极易溢出，即使结果存入 long 变量也已失真
时间戳与高精度计时
系统级时间通常以毫秒或纳秒为单位，int 根本无法容纳——例如 System.currentTimeMillis() 自 1970 年起累计毫秒数，2026 年已超 1.7 × 1012，远超 int 上限。
- 所有标准时间 API（
Instant、Duration、System.nanoTime()）内部均基于 long - 分布式系统中生成唯一时间序 ID（如 Snowflake 的 timestamp 部分）也强依赖 long 表达毫秒/微秒精度
- 做时间差计算时，直接用 long 相减即可，单位统一、无精度损失
主键、计数器与大容量标识
当数据库自增主键、全局请求 ID 或实时统计计数器可能突破 21 亿时，int 就成了瓶颈。
- MySQL 的
BIGINT、PostgreSQL 的bigint默认映射为 Java long，保持类型一致 - 高并发场景下的原子计数器（如
AtomicLong）用 long 可支撑万亿级累计值 - 文件大小、内存用量、网络字节数等系统资源度量，常达 GB/ TB 级，必须用 long 表达字节数（如
1024L * 1024L * 1024L）
避免误用与性能权衡
long 不是万能解药。它占 8 字节，是 int 的两倍，在内存敏感或缓存密集型场景中需谨慎。
- 数组索引、循环变量、状态码等小范围值，坚持用 int —— JVM 对其优化更成熟，CPU 缓存更友好
- 序列化大量 long 字段会显著增大 payload，必要时考虑压缩（如 delta 编码 + varint）
- 跨语言交互（如 gRPC、JSON）要注意 long 在 JavaScript 中精度丢失（JS Number 最大安全整数为 253−1），建议传字符串或拆分为高低位
