long類型64位，JS的Number精度只有53位，所以后台數據傳到前端的時候，精度丟失，后面幾位被置為0了。
嘗試過的解決辦法：
1、在Long類型字段上使用注解標明序列化方式。此方式細粒度到當前字段，我嘗試了幾種方法之后選用了此方法。
@JsonSerialize(using = ToStringSerializer.class)
private Long id;
2、自定義解析方法
/**
* 解決Jackson導致Long型數據精度丟失問題
*
* @return
*/
@Bean("jackson2ObjectMapperBuilderCustomizer")
public Jackson2ObjectMapperBuilderCustomizer jackson2ObjectMapperBuilderCustomizer() {
Jackson2ObjectMapperBuilderCustomizer customizer =
jacksonObjectMapperBuilder -> jacksonObjectMapperBuilder
.serializerByType(Long.class, ToStringSerializer.instance)
.serializerByType(Long.TYPE, ToStringSerializer.instance);
return customizer;
}
3、自定義ObjectMapper，沒找到代碼就不寫了。
4、自定義MappingJackson2HttpMessageConverter，此方法可以指定攔截哪些請求(其他方法應該也可以實現)才做處理。
當然還有其他方法自行百度吧。
其中，后面幾種方法是把返回的實體中所有的long類型都轉成了字符串類型，項目中應該根據實際需要，選取合適的方案。
背景：
最近工作中，被運維要求整改mysql數據庫表，大體分兩類：無主鍵 和 使用了自增ID。
無主鍵的表，就加個主鍵唄，還能提升查詢效率，一句sql搞定。
使用自增ID的表，就把自增去掉唄，然后根據業務需要，大概找了一些分布式ID生成方案做參考，選用了美團的leaf中snowflake的實現（其他方案可以自行百度），源碼見鏈接 https://github.com/Meituan-Dianping/Leaf 。
簡單聊一下，long類型一共64位，去掉一個符號位，10位workID，12位自增序列，還有41位取時間戳差值，簡單算一下可以使用69年(估計我不在了，程序還在)。這樣一算，10位workID最多支持1024個節點(一台機器上的一個服務對應一個節點)同時注冊(目前我們所有節點加一起應該不超過50個)，workID使用ZK的順序節點實現，12位自增序列每ms就有4000個左右(每秒就可以生成400W個ID)，這樣完全滿足我們業務使用了。
后端改好了美滋滋，打包，上環境，完了，各種報錯。