本文转载自微信公众号《小姐姐的味道》，作者小姐姐养的狗。转载本文请联系味觉小姐公众号。这是正确的。前端用来坑后端。我只能在这里说这种无耻的话。因为xjjdog的修为主要体现在后端，所以爱宅爱乌鸦。这反映出奋斗是人的基本属性：程序员除了身为产品经理和项目经理，内在也不是铁板一块。但是我这次要说的问题真的很棘手。它几乎让整个系统瘫痪，让暴躁的老板长满了青春痘。它的影响不仅限于此。扩展到整个行业：过去能发财的都破产了。本来能结婚，分手了。原来能钓到鱼的都得加班加点。原来是前端在搞后端。本来可以退休的，推迟了。那些本可以活着的人都死了。原来可以双休，一晃就是一周了。为什么狂妄的js这么厉害？请详细听我说。1.事情发生是有原因的正如标题所说，这将与雪花算法有关。我们有一个使用MySQL数据库的系统，所以在数据库主键的选择上，使用了自增ID。像IDINTPRIMARYKEYAUTO_INCREMENT这样的ID虽然简单流畅，但是也有一系列的缺点，但是对于一般的系统来说已经足够了。项目上线前，项目组请来了公司最优秀的架构师，对项目进行了集中体检。其中一项重要措施是针对ID生成器。“不知道现在的开发系统是不是至少要用Snowflake作为ID生成器？”架构师对自增ID的方案很不满意。指出即使使用UUID，遇到系统扩容、分库分表、数据迁移等场景，也比自增ID好，大家讨论后觉得很有道理。UUID太乱，美团Leaf太复杂。不如直接用老的Snowflake生成最简单的ID。像这样的东西。527574217068392807527574217068392808为了给大家一个直观的认识，我们来看一下Java中Long的最大值。9223372036854775807再看Int的最大值。2147483647可以看到生成的SnowflakeID是一个大于Int小于Long的值（与最大值比较），所以数据库中使用bigint存储比较好。说干就干，批处理脚本一改，主键就会变大变长~~~2。问题先不说，这样的ID看着顺眼多了。ID在URL和formdata中传递，一看就很专业！/edit.do?id=527574217068392810按照建议修改系统后，单元测试很顺利。黑盒测试草草点了一下，就算通过了。客户发现了超自然事件。客户说，很多记录不能编辑或删除。提示找不到记录。很多公司的尿性你也知道。在与客户交流时，他们通常对技术了解不多。面对着客户的屏幕，我用我牛逼的手机拍照，发过来的原图十几MB。但奇葩的是图片很大，内容却很模糊。后台程序员眯着眼睛打开图片，把里面显示的ID拉出来，在系统里查看。没有这样的记录。眯眼的姿势肯定有问题。后端程序员不得不重新记录一遍。遗憾的是，目前还没有这样的记录。没办法，只好复制客户的数据库。点开页面，确实有问题！浏览器响应中返回的数据实际上与预览中的不同。3、问题验证也就是说，一个好的数字：527183991665594368，经过浏览器翻译后，变成了527183991665594400，我们在浏览器的devtools中调试一下。为了进一步验证，我们从typescript到js进行实验。#cattest.tsleta=527183991665594368;console.log(a);#tsctest.ts#cattest.jsvara=527183991665594368;console.log(a);#nodetest.js527183991665594400可以看到整个js生态都存在这个问题后端真的坏了。4.为什么？这是因为。在JavaScript中，有两种数字。数字和BigInt。最常用的是数字。最大的数字称为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的封装，但是还是太麻烦了，需要编码的太多了，可能会漏掉。使用数字类型传输数据确实不可靠。如果你转身，情况就不一样了。最好的方法是使用字符串来传递。就算以后后台ID的长度变成128位，也不怕这个转换。在Java中，如果使用jackson，可以直接通过注解完成字符串的改变，不需要改变数据库。@JsonSerialize(using=ToStringSerializer.class)privateLongid;这个问题显然不是后端的锅。后端向前端传输正确的数据，能不能处理，与后端完全没有关系。JS按照规范的非标准处理，已经让很多人踩坑了。不管是新人还是老鸟，还是相继掉坑里。不得不说这个功能非常反人类。尽管如此，我们还是在后端解决了这个问题。谁叫我们走全栈路线的？如果有必要，我们甚至可以做产品工作！作者简介：品味小姐姐（xjjdog），一个不允许程序员走弯路的公众号。专注于基础架构和Linux。十年架构，每天百亿流量，与你探讨高并发世界，给你不一样的滋味。我的个人微信xjjdog0，欢迎加好友进一步交流。
