最近公司的一個項目組要把以前的單體應(yīng)用進(jìn)行為服務(wù)拆分，表的ID主鍵使用Mybatis plus默認(rèn) 的雪花算法來生成。

快下班的時候，小伙伴跑過來找我，：“快給我看看這問題，卡這卡了小半天了！”。連拉帶拽，連哄帶騙的把我拉到他的電腦前面。這位小伙伴在我看來技術(shù)不算是大牛，但經(jīng)驗也很豐富了。他都卡了半天的問題，應(yīng)該不是小問題，如果我一時半會搞不定，真的是耽誤我下班了，所以我很不情愿的在他的位置坐了下來。

一、現(xiàn)象是這樣的

下面我把異常的現(xiàn)象給大家描述一下，小伙伴建了一張表，表的主鍵是id BigINT，用來存儲雪花算法生成的ID，嗯，這個沒有問題！

CREATE TABLE user
(id BIGINT(20) NOT NULL COMMENT '主鍵ID',#其他字段省略
);

使用Long 類型對應(yīng)數(shù)據(jù)庫ID數(shù)據(jù)。嗯，也沒有問題，雪花算法生成的就是一串?dāng)?shù)字，Long類型屬于標(biāo)準(zhǔn)答案！

@Data
public class User {private Long id;
//其他成員變量省略

在后端下斷點?？吹綌?shù)據(jù)響應(yīng)以JSON響應(yīng)給前端，正常

{
id：1297873308628307970,
//其他屬性省略
}

最后，這條數(shù)據(jù)返回給前端，前端接收到之后，修改這條數(shù)據(jù)，后端再次接收回來。奇怪的問題出現(xiàn)了：后端重新接收回來的id變成了：12978733086283000000，不再是1297873308628307970

二、分析問題

我的第一感覺是，開發(fā)小伙伴把數(shù)據(jù)給搞混了，張冠李戴了，把XXX的對象ID放到了YYY對象的ID上。所以，就按照代碼從前端到后端、從后端到前端調(diào)試跟蹤了一遍。

從代碼的邏輯角度上沒有任何問題。這時，我有點煩躁了，真的是耽誤我下班了！但開工沒有回頭箭，既然坐下來了就得幫他解決，不然以后這隊伍怎么帶？想到這我又靜下心來，開始思考。

1297873308628300000 ---> 1297873308628307970

這兩個數(shù)長得還挺像的，似乎是被四舍五入了。此時腦袋里面冒出一個想法，是精度丟失了么？哪里能導(dǎo)致精度丟失？

• 服務(wù)端都是Long類型的id，不可能丟失
• 前端是什么類型，JSON字符串轉(zhuǎn)js對象，接收Long類型的是number

上網(wǎng)查了一下Number精度是16位（雪花ID是19位的），So：JS的Number數(shù)據(jù)類型導(dǎo)致的精度丟失。問題是找到了！
小伙伴投來敬佩的眼光，5分鐘就把這問題發(fā)現(xiàn)了?？墒前l(fā)現(xiàn)了有什么用？得解決問題啊！

三、解決問題

開發(fā)小伙伴說：那我把所有的數(shù)據(jù)庫表設(shè)計，id字段由Long類型改成String類型吧。我問他你有多少張表？他說100多張吧。

• 100多張表還有100多個實體類需要改
• 還有各種使用到實體類的Service層要改
• Service等改完Controller層要改
• 關(guān)鍵的是String和Long都是常用類型，他還不敢批量替換

小伙伴拿起電話打算訂餐，說今晚的加班是無法避免了。我想了想說：你最好別改，String做ID查詢性能會下降，我再想想！后端A到前端B出現(xiàn)精度丟失，要么改前端，要么改后端，要么…… ?！鞍グ?#xff0c;你等等先別訂餐，后端A到前端B你用的什么做的序列化？” 小伙伴告訴我說使用的是Jackson，這就好辦了，Jackson我熟悉啊！

---

解決思路：后端的ID(Long) ==> Jackson(Long轉(zhuǎn)String) ==> 前端使用String類型的ID,前端使用js string精度就不會丟失了。?那前端再把String類型的19位數(shù)字傳回服務(wù)端的時候，可以用Long接收么？當(dāng)然可以，這是Spring反序列化參數(shù)接收默認(rèn)支持的行為。

---

最終方案就是：前端用String類型的雪花ID保持精度，后端及數(shù)據(jù)庫繼續(xù)使用Long(BigINT)類型不影響數(shù)據(jù)庫查詢執(zhí)行效率。

剩下的問題就是：在Spring Boot應(yīng)用中，使用Jackson進(jìn)行JSON序列化的時候怎么將Long類型ID轉(zhuǎn)成String響應(yīng)給前端。方案如下：

@Configuration
public class JacksonConfig {@Bean@Primary@ConditionalOnMissingBean(ObjectMapper.class)public ObjectMapper jacksonObjectMapper(Jackson2ObjectMapperBuilder builder){ObjectMapper objectMapper = builder.createXmlMapper(false).build();// 全局配置序列化返回 JSON 處理SimpleModule simpleModule = new SimpleModule();//JSON Long ==> StringsimpleModule.addSerializer(Long.class, ToStringSerializer.instance);objectMapper.registerModule(simpleModule);return objectMapper;}}

小伙伴放下電話， 再次投來敬佩眼光?！白甙?#xff0c;一起下班！”我和小伙伴說，小伙伴一路上一直問我你是怎么學(xué)習(xí)的？我冠冕堂皇的說了一些多想多學(xué)多問之類的話。
其實我心里在想：我是一個懶人，但我不能說。能躺著絕不坐著，能自動絕不手動，能打車絕不自己開車。第一次就把事情做對，才是省時省力做好的方法！這么多年的“懶”，決定了我需要去思考更多的“捷徑”，思考“捷徑”的過程是我不斷進(jìn)階的訣竅！
勤奮的人是社會的生產(chǎn)力，而懶人是社會的創(chuàng)造力！