js处理long精度丢失

1、业务背景

调用接口返回数据实体,id是long类型,浏览器(谷歌)进行访问返回的id最后两位变成0了,精度丢失。但是通过postman是正常的。

2、问题分析

这是因为在 JavaScript 中,数字类型默认会被转换为双精度浮点数,而双精度浮点数的精度有限,只能精确表示 2 的 53 次方以内(即 Number.MAX_SAFE_INTEGER,约为 9 x 10^15)的整数。对于超过该范围的长整数,JavaScript 会发生精度丢失,导致值变得不准确(前端JavaScript最大只能接收16位数字)。

3、问题验证

打开浏览器,按F12调出控制台,在控制台中输入 console.log(9223372036854775807) ,打印的结果与传入的参数不一致

4、解决方案

方法一,在属性上添加注解:@JsonSerialize(using = ToStringSerializer.class),将数值转换为字符串

	/**
     * 用户ID
     */
    @JsonSerialize(using = ToStringSerializer.class)
    @Excel(name = "用户序号", cellType = ColumnType.NUMERIC, prompt = "用户编号")
    private Long userId;

方法二,在application.properties配置文件中添加配置:

spring.jackson.serialization.WRITE_DATES_AS_TIMESTAMPS=false
# 将 long 类型序列化为字符串类型
spring.jackson.generator.write-numbers-as-strings=true

注意:此方式,会影响所有的接口,所有接口中的数字字段,都会被转换为字符串输出
其中,WRITE_DATES_AS_TIMESTAMPS 表示是否将日期类型序列化为时间戳类型,默认为 true,这里设置为 false 如果需要将日期类型序列化为时间戳类型,则不需要设置此属性。而 WRITE_NUMBERS_AS_STRINGS 则表示是否将数字类型序列化为字符串类型,默认为 false,这里设置为 true 即可将 long 类型序列化为字符串类型。

方法三,spring boot项目中添加jackson配置:

@Configuration
public class BigNumberHandlerConfig {
    @Bean
    public MappingJackson2HttpMessageConverter jackson2HttpMessageConverter() {
        MappingJackson2HttpMessageConverter converter = new MappingJackson2HttpMessageConverter();
        ObjectMapper mapper = new ObjectMapper();
        //数字转字符串
        SimpleModule simpleModule = new SimpleModule();
        simpleModule.addSerializer(Long.class, ToStringSerializer.instance);
        simpleModule.addSerializer(Long.TYPE, ToStringSerializer.instance);
        simpleModule.addSerializer(Float.class, ToStringSerializer.instance);
        simpleModule.addSerializer(Float.TYPE, ToStringSerializer.instance);
        simpleModule.addSerializer(Double.class, ToStringSerializer.instance);
        simpleModule.addSerializer(Double.TYPE, ToStringSerializer.instance);
        simpleModule.addSerializer(BigInteger.class, ToStringSerializer.instance);
        mapper.registerModule(simpleModule);
        converter.setObjectMapper(mapper);
        return converter;
    }
}
### Java前后端Long类型精度丢失解决方案 在Java与前端交互过程中,由于JavaScript的`Number`类型的数值范围有限(约为±(2^53)-1),而Java的`Long`类型可以表示更大的整数范围(约±(2^63)-1)。因此,在前后端传递大数值时容易发生精度丢失问题。 以下是几种常见的解决方案: #### 方案一:后端将Long类型转为String类型发送到前端 通过修改后端代码,将`Long`类型的字段序列化为字符串形式后再传递至前端。这样可以有效避免因数值过大而导致的精度丢失问题[^1]。 ```java import com.fasterxml.jackson.databind.annotation.JsonSerialize; import com.fasterxml.jackson.databind.ser.std.ToStringSerializer; @Data @TableName("ap_article") public class ApArticle implements Serializable { @TableId(value = "id", type = IdType.ID_WORKER) @JsonSerialize(using = ToStringSerializer.class) // 将字段转换为字符串进行响应 private Long id; } ``` 此方法利用Jackson库中的`ToStringSerializer`实现自动转换功能[^5]。 --- #### 方案二:前端使用BigInt替代Number类型 对于现代浏览器环境下的应用开发,可以通过让前端采用`BigInt`来代替传统的`Number`类型处理大数据量场景下可能出现的问题[^4]。需要注意的是该特性仅适用于支持ES2020及以上版本标准的新一代Web客户端程序设计框架之中。 例如: ```javascript let bigIntValue = BigInt('1435421253099634623'); console.log(bigIntValue.toString()); // 输出完整的原始值 ``` 这种方式要求服务端仍然保持原有的数据结构不变,只是调整了客户端解析逻辑[^2]。 --- #### 方案三:统一约定并限制ID长度 如果项目允许的话,也可以考虑重新规划业务模型中的唯一标识符生成策略,比如缩短其位宽或者选用其他更适合跨平台共享的数据格式作为主键定义依据之一[^3]。不过这种方法通常会带来额外的工作负担以及潜在的风险因素,故需谨慎评估实施成本效益比之后再做决定。 --- #### 总结 以上三种方式各有优劣之处,具体选择哪一种取决于实际应用场景需求和技术栈现状等因素综合考量结果得出结论。一般推荐优先尝试第一种做法即借助JSON序列化工具包完成自动化映射操作最为简便高效;而对于那些追求极致性能优化或者是老旧系统升级改造工程,则可能需要结合第二种甚至第三种手段共同作用才能达到理想效果。 ```python # 示例Python伪代码展示如何验证上述理论正确性的简单测试脚本 def test_long_precision(): large_number_str = '1435421253099634623' try: # JavaScript Number 类型无法精确存储这个数字 number_value = float(large_number_str) print(f'Float representation: {number_value}') # 使用 Python 的 int 或者 str 来保留原样 exact_representation_via_int = int(large_number_str) print(f'Exact via Int: {exact_representation_via_int}') exact_representation_via_string = large_number_str print(f'Exact via String: "{exact_representation_via_string}"') except Exception as e: print(e) test_long_precision() ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

strggle_bin

一毛不嫌少,十元不嫌多

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值