java long本身不精度丢失，因其64位整型可精确表示毫秒级时间戳（当前值约1.7×10¹²，远低于long上限9.2×10¹⁸）；精度丢失实际发生在json传输至javascript时，因js number仅能安全表示≤2⁵³−1的整数，超限后解析即四舍五入。
用 long 存时间戳本身不会精度截断——它原生支持 64 位整数，能精确表示毫秒级 Unix 时间戳（范围约 ±292 年），关键在于全程保持整数语义、避免跨语言传输时被 JavaScript 自动转成浮点数。
为什么 long 本身不丢精度
Java 的 long 是有符号 64 位整型，取值范围是 −9,223,372,036,854,775,808 到 9,223,372,036,854,775,807。而毫秒级时间戳（如 System.currentTimeMillis() 或 Instant.now().toEpochMilli()）当前最大值才约 1.7×10¹²（2026 年），远未触及 long 上限。所以在 Java 内部运算、存储、数据库 bigint 字段映射中，long 完全够用且无精度损失。
精度丢失真正发生在哪里
问题不出在 Java，而出在前后端 JSON 传输环节：JavaScript 的 Number 类型是 IEEE 754 双精度浮点数，仅能安全表示 ≤ 2⁵³−1（即 9,007,199,254,740,991）的整数。一旦后端返回的 long 值（如雪花 ID 或未来年份的时间戳）超过该阈值，前端解析就会四舍五入——比如 1629872445049 没事，但 9223372036854775807 就会变成 9223372036854776000。
- 典型高危字段：分布式 ID（Snowflake）、远期时间戳（如 2120 年的到期时间）、大文件最后修改时间
- 验证方式：Postman 看响应体是正确的，浏览器 console 打印却变了 → 基本锁定为 JS 解析问题
正确做法：从源头隔离浮点风险
核心原则：只要涉及可能超 2⁵³ 的 long 值对外输出，一律转 String。
-
序列化层统一处理：用 Jackson 时加
@JsonFormat(shape = JsonFormat.Shape.STRING)注解；Fastjson 同理配@JSONField(serializeUsing = ToStringSerializer.class) -
DTO 字段显式声明为 String：比如
private String orderId;而非private Long orderId;，接收时再按需 parseLong（仅在可信上下文） -
数据库交互保持 bigint：MySQL/PostgreSQL 的
BIGINT与 Javalong映射天然匹配，JDBC 驱动默认正确转换，无需额外干预
时间戳单位换算别踩坑
业务计算中要用 TimeUnit，而不是手写 *1000 或 /60/60：
-
TimeUnit.SECONDS.toMillis(30)→ 安全得 30000，类型仍是 long -
TimeUnit.MILLISECONDS.toSeconds(System.currentTimeMillis())→ 自动向下取整，语义清晰 - 避免
(int) TimeUnit.HOURS.toMillis(2)：强转可能溢出，直接用 long 接收 - 日志展示需要小数？用
ms / 1000.0—— 这是展示需求，不是精度换算，和 TimeUnit 场景不同
不复杂但容易忽略
