本文转载自微信大众号「小姐姐滋味」，作者小姐姐养的狗 。转载本文请联络小姐姐滋味大众号。

没错。前端，便是用来坑后端的。

我也只能在这里，宣布这样无耻的言辞。由于xjjdog的修为首要表现在后端上，所以爱屋及乌。这表现了奋斗是人类的底子特点：程序员除了要干产品司理、项目司理，内部也并不是铁板一块。

不过这非必须聊的问题，确实是很坑。它简直断送了整个体系，让浮躁的老板脸上爆破式的长满了痘痘。

它的影响不限于此。扩大到整个业界：

本来能发财的，破产了。

本来能成婚的，分手了。

本来能摸鱼的，加班了。

本来搞前端的，搞后端了。

本来能退休的，延期了。

本来能活着的，逝世了。

本来能双休的，大小周了。

为什么牛气的js，会有这么大的威力?请听我细细道来。

1. 事出有因

就如标题所说，这个会和雪花算法有关。

咱们有个体系，运用的是MySQL数据库，所以在数据库的主键挑选上，运用的是自增ID。

IDINTPRIMARYKEYAUTO_INCREMENT

这样的ID简略流通，但有一系列的坏处，不过用在一般的体系上，够用了。

在临上线之前，项目组约请公司里最牛x的架构师，对项目进行了一次会集体检。其间的一项重要行动，便是针对于ID生成器的。

“不知道现在的开发体系，都至少要运用Snowflake作为ID生成器么?” 架构师对自增ID的计划十分的不满意。

它指出，哪怕你运用UUID，在遇到体系扩容、分库分表、数据搬迁等场景的时分，也比自增ID强。

大家伙一评论，觉得十分合理。UUID太无序，美团Leaf这种又太杂乱，还不如直接运用老掉牙的Snowflake，直接生成最简略的ID即可。

类似于这种。

527574217068392807
527574217068392808

为了让你有个直观的知道，咱们看一下Java中Long的最大值。

9223372036854775807

再看一下Int的最大值。

2147483647

能够看到生成的Snowflake ID，是比Int大，比Long小的数值(和最大的比较)，所以在数据库中运用bigint存储，再好不过了。

说干就干，批量脚本一改，主键就变大变长了~~~

2. 问题产生

甭说，这姿态的ID，看起来还比较顺眼。ID在URL里传递，在formdata里传递，一看就比较的专业！

/edit.do?id=527574217068392810

体系依照主张改完之后，单元测验很流通。黑盒测验草草的点了一下，就算经过了。

灵异事情是被客户发现的。

客户说，许多记载，无法修改、无法删去。提示找不到记载。

许多公司的尿性你也是知道的，和客户沟通的，一般不太懂技能。对着客户的屏幕用牛x的手机摄影，原图发过来就有十几MB。但灵异的是图片大，内容却模模糊糊。

后端程序员，眯着眼睛翻开图片，把里边显现的ID给抠出来，放在体系里一查。

没有此记载。

肯定是眯眼的姿态有问题。后端程序员不得不再录一遍。惋惜的是，仍然没有这条记载。

没办法，只好把客户的数据库复制一份过来。页面上一点击，果然有问题!

浏览器response里回来的数据居然和preview里的不一样

3. 问题验证

也便是说，一个好好的数字：527183991665594368，经过浏览器一翻译，变成了527183991665594400。

咱们在浏览器的devtools里边调试一下。

为了进一步验证，咱们从typescript到js，都实验一下。

#cattest.ts
leta=527183991665594368;
console.log(a);
#tsctest.ts
#cattest.js
vara=527183991665594368;
console.log(a);
#nodetest.js
527183991665594400

能够看到，在整个js的生态里，都存在这个问题，真是坑坏了后端。

4. Why?

这是由于。在JavaScript中，存在两种数字。Number和BigInt。最常用的，便是number。

最大的Number，叫做Number.MAX_SAFE_INTEGER，它的值为：

2^53-1 或许

+/- 9,007,199,254,740,991

众所周知，Java中的Long，是64位的。Js中的这个安全Integer，彻底达不到Java中界说的长度。

这便是万恶的IEEE_754标准，它在Long长度大于17位时会呈现精度丢掉的问题。

在最新的TypeScript3.2中，但是直接运用BigInt这个类型进行编码，或许运用long.js这种封装后的苦，但仍是太麻烦了，需求编码太多，并且还或许漏掉。

运用数字类型，传输数据，实在是不太靠谱，转来转去，就物是人非了。

最好的方法，便是运用string进行传递。哪怕今后后台ID的长度变成了128位的，也不惧怕这种转化。

在Java中，假如你用的是jackson，直接经过注解，就能够完结字符串更改，不需求再改动数据库。

@JsonSerialize(using=ToStringSerializer.class)
privateLongid;

这问题，显着不是后端的锅。后端传递了正确的数据到前端，能不能处理、处理的正确不正确，底子和后端一点联系都没有。JS的这种依照标准的不标准处理，现已让许多人踩坑。不管是萌新，仍是老鸟，仍然前赴后继的掉到坑里，不得不说这个特性是十分反人类的。

不过，咱们仍是在后端处理了。谁让咱走的是全栈路线呢?必要时，连产品的活儿都能做!

作者简介：小姐姐滋味 (xjjdog)，一个不允许程序员走弯路的大众号。聚集根底架构和Linux。十年架构，日百亿流量，与你讨论高并发国际，给你不一样的滋味。我的个人微信xjjdog0，欢迎增加老友，进一步沟通。