Java的长整型可精确存储大时间戳,但跨语言JSON传输至JavaScript时,由于JavaScript的数字类型采用双精度浮点数,仅能安全表示2的53次方以内的整数,超过则精度丢失。解决方法:对外输出可能超限的长整型值一律转为字符串。
在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 场景不同
不复杂但容易忽略,只要记住上面几点,基本就能稳住了。