如何正确使用long类型8字节内存存储大时间戳以避免精度截断

在Ja va的世界里，用`long`存时间戳到底会不会丢精度？这个问题看似简单，却常让不少开发者踩坑。先说结论：`long`本身完全没问题，精度丢失的锅，多半要甩给跨语言传输——特别是Ja vaScript那一端。 先理解一下为什么`long`在Ja va内部是安全的。Ja va的`long`是有符号64位整型，取值范围从-9.22×10¹⁸到9.22×10¹⁸，而当前毫秒级时间戳（比如`System.currentTimeMillis()`返回的值）大约在1.7×10¹²左右，离`long`的上限还差着好几个数量级。所以，**在Ja va内部运算、存储、甚至数据库的BIGINT字段映射中，long完全可以精确表示，没有任何精度损失**。 那精度丢失到底发生在哪里？答案就在JSON传输这个环节。Ja vaScript的`Number`类型采用的是IEEE 754双精度浮点数，它只能安全表示绝对值小于等于2⁵³−1（约9.007×10¹⁵）的整数。一旦后端返回的`long`值超过这个阈值，前端解析时就会悄悄四舍五入。打个比方：`1629872445049`这个值没问题，但换成`9223372036854775807`，到了浏览器里就变成了`9223372036854776000`——这种肉眼可见的偏差，只要你在Postman里看响应体是对的，但打开浏览器控制台一打印发现变了，基本就锁定了是JS浮点解析造成的。 那么哪些场景最容易中招呢？典型的有分布式ID（比如Snowflake算法生成的ID）、远期时间戳（比如2120年的到期时间）、大文件的最后修改时间。验证方法很简单：后端返回后，分别用Postman和浏览器控制台对比一下结果，不一致就说明问题出在JSON解析上。 正确的做法是从源头隔离浮点风险，核心原则只有一句话：**只要涉及可能超过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`与Ja va的`long`天然匹配，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`的使用场景不同。 说到底，这其实不复杂，但容易忽略。只要记住“跨语言传输时long超限要转String”这一条，就能避开大部分坑。

为什么 long 本身不丢精度

Ja va 的 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 上限。所以在 Ja va 内部运算、存储、数据库 bigint 字段映射中，long 完全够用且无精度损失。

精度丢失真正发生在哪里

问题不出在 Ja va，而出在前后端 JSON 传输环节：Ja vaScript 的 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 与 Ja va long 映射天然匹配，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 场景不同

不复杂但容易忽略，只要记住上面几点，基本就能稳住了。