1、业务背景

有个同事找我帮他看一个问题，他给前端提供了一个接口。

这个接口是用来反查id的，他这里这个参数正常的返回值应该是 283232039247028226。

但前端反馈他，前端在浏览器（火狐）获取的值是 283232039247028220（而且前端返回的这个值，并不存在于他的数据库中）。

而且他用浏览器(谷歌）进行访问返回的值也和前端一样是个错误值

Postman请求的值：

前端浏览器（火狐）请求的值：

2、问题分析

我用Edge浏览器进入前端页面查看，发现我这里返回的值和Postman是一致的

随后我去数据库查询他们得到的错误值，发现数据库是不存在的。既然数据库不存在，且不是所有浏览器都能复现，那应该就不是代码逻辑问题捞取到错误的值了。

随后我将正确的值、和他返回错误的值的值进行对比，发现整体是大致一样的，只有最后一位数不同。这个时候我就大概率感觉应该是精度损失的问题了！

随后一看他的代码，返回类型是用的Long类型的字段。百度得知前端JavaScript最大只能接收16位数字，故会导致精度丢失，以至于最后一位的6变成了0。（至于Edge为什么没有精度损失，怀疑可能是底层对其有一定的兼容）

3、解决方案

既然问题产生的原因已经很清晰了，那解决方案很简单，就是将原本的Long类型，修改为String类型，即可解决精度损失的问题。

4、总结

对于过长的id，尽量使用String进行存储和传递。因为你最多能确保在你这里是不会精度损失的，但你不能确保调用你接口的其他地方是以什么形式来解析你的id的。