前端VS后端：这个锅你背不背！
hello大家好，小面又和大家见面了，今天来给大家吐糟下前端js语言对numer类型的设定。
引言
事情是这样的，小面接到了开发几个接口的任务，其中有个数据库表的主键id数据类型是bigint。
而这张表之前没有增删改查，都是直接在版本发布之前配置的insert语句，当然数据也不多，就那么20多条。
大家平常在开发中应该也有类似的数据库表，本身就不多变的数据只需要配置下就可以了。
由于是手动写的sql，当然id就是1到20咯，大家看下脚本语句
再看下数据库表中的数据
就是这么简单的一个表，要做的功能就是对这个表数据的增删改查。
对大家来说应该很简单吧，是的小面也是一样心态，没想到在和前端联调时也萌萌哒。
出现的问题
问题就是小面利用postman自测列表查询，得到的结果比对数据库id是没问题的。
但是前端页面展示和接口返回的数据里id有重复值和后端数据库的id值有很大的区别。
前端返回接收到的数据：
后端数据库的数据：
后端数据库表结构：
postman调用接口返回的数据
问题显而易见了吧，就是返回给前端的数据不对。
当时小面脑袋就想这TM什么神仙问题，怎么会这样，不过问题出现了还是得冷静下来进行分析...
问题分析
postman接口测试正常，前端小伙伴用的是vue，我们大概都知道vue是目前最火的前端框架了。
它也是对js进行了封装，刨其根本就是js接收数据的问题了，那先百度下看看有没有伙伴遇到类似问题
果然有同样踩坑的同学呀，跟着大家的经验去走一走，看看是不是这个问题咯。
然后查了一下，JS中number最大值是支持17位的，最大值是Number.MAX_VALUE ，它是 js的一个常量，表示js可表示的最大值 ，值为 1.7976931348623157e+308。
我们后端的bigint返回的long类型超过了17位就会造成精度丢失，所以就出现了前后端看到数据不一致的情况。
当然数据都不一致了，依靠id修改删除的操作就无法保证了。
解决
解决方法就是将返回给前端的id数据类型有Long改为String就正常了，是不是非常的简单，却是一个坑。
总结
今天的分享到这就结束了，相信你通过小面的实际开发案例对于Js中number精度丢失有了一印象，以后遇到这种情况就不会惊慌。
也可以在设计表阶段就规避这些问题，比如我用的这个type相关表，本身就没有多少数据，没有必要使用bigint。
但为何会设计成这样呢？
我去问了下同伴，说以前设计的时候统一规划的，当时就想着数据类型保持一致，所以就这样了。
有同学可能会问，为何不改数据库表的字段类型，这的确是个好问题，那小面为何不改呢？
这个改了会牵涉之前的功能改动，之前的功能改动会影响这个服务核心业务功能，改会增加自身工作量，也会给团队增加工作量。
还会给测试团队增加工作量，拿上去评估就是先这样把，不改。
估计大多数小伙伴和小面情况一样，遇到可优化的问题能改，可是改了会关联影响核心业务，除非实现不了才会改的这样一个现状。
如果有被说中，请多多点赞和再看，甚至可以动动手指帮小面转发一下，让大家少踩坑！