Redmi Pad評測：紅米充滿野心的一次嘗試
從Note系列到K系列，從藍(lán)牙耳機(jī)到筆記本電腦，紅米不知不覺之間也已經(jīng)形成了自己頗有競爭力的產(chǎn)品體系，在中端和次旗艦市場上甚至要比小米新機(jī)的表現(xiàn)來得更好，正所謂“大丈夫生居
在進(jìn)行數(shù)據(jù)結(jié)構(gòu)設(shè)計時，我們通常需要考慮到相關(guān)業(yè)務(wù)的數(shù)據(jù)量等因素。比如非核心業(yè)務(wù)但數(shù)據(jù)量大并且頻繁寫入的表的主鍵，我們可能會考慮設(shè)計為Long類型。剛開始，數(shù)據(jù)量小，可能并不會發(fā)現(xiàn)什么問題。但是當(dāng)數(shù)據(jù)量大了，或者Id采用雪花算法生成，這個時候詭異的事情便會發(fā)生。
后端數(shù)據(jù)正常返回，postman調(diào)試看數(shù)據(jù)也正常。但是當(dāng)前端用后端返回的這個id查詢相應(yīng)的數(shù)據(jù)時，便會發(fā)生詭異的NotFoundException，或者查詢的出來的數(shù)據(jù)和原先的數(shù)據(jù)不一致。
所以，誰偷偷動了我的代碼？
如果只從后端分析問題，或者只從前端分析問題，那永遠(yuǎn)也找不到答案。
在 JavaScript 中，數(shù)值類型默認(rèn)會被轉(zhuǎn)換為雙精度浮點數(shù)，而雙精度浮點數(shù)的精度有限，只能精確表示 2 的 53 次方以內(nèi)（即 Number.MAX_SAFE_INTEGER，約為 9 x 10^15）的整數(shù)。對于超過該范圍的長整數(shù)，JavaScript 會發(fā)生精度丟失，導(dǎo)致值變得不準(zhǔn)確。
例如一個雪花算法生成的ID 1734042308679487490，前端獲取到的值卻變成了1734042308679487500
知道了問題的原因，問題就容易解決了——將Long類型作為String類型返回給前端即可。
(1) Spring Boot 中提供了 @JsonFormat 注解，可以對實體類中的屬性進(jìn)行序列化和反序列化格式化。對于 Long 類型的屬性，可以設(shè)置其格式為字符串類型，并在前端進(jìn)行相應(yīng)的處理，以保持其精度不丟失。如：
public class Order { @JsonFormat(shape = JsonFormat.Shape.STRING) private Long id; ...}前端獲取到的是string類型的數(shù)據(jù)，自然也不會有精度丟失的問題了。
(2) SpringBoot也支持在通過配置文件在項目級別，將數(shù)值類型的數(shù)據(jù)轉(zhuǎn)成字符串返回給前端，通過在 application.properties 文件中添加配置即可:
# 默認(rèn)為falsespring.jackson.seralization.WRITE_NUMBER_AS_STRINGS=true(3) 如果不想使用 @JsonFormat 注解或者項目不是基于SpringBoot框架構(gòu)建的，同樣的思路，直接將Long類型轉(zhuǎn)換成String返回給前端即可。
在 JavaScript 中數(shù)值類型最大精度大約為9*10^15，即超過16位的數(shù)值一定會存在精度丟失問題。因此，后端返回Long類型的數(shù)值時，需要轉(zhuǎn)換成String給到前端。
本文鏈接：http://www.www897cc.com/showinfo-26-44400-0.html誰動了我的代碼——Long精度丟失
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號