JavaScript大數(shù)ID精度丟失問題的解決方案
問題背景
在前后端分離的Web應(yīng)用開發(fā)中，經(jīng)常會遇到一個令人頭疼的問題：JavaScript數(shù)字精度丟失。當后端使用Long類型生成的大數(shù)ID傳遞到前端時，會出現(xiàn)精度丟失，導致前端獲取的ID與后端實際存儲的ID不一致。
問題現(xiàn)象
在我們的若依(RuoYi)郵件服務(wù)器管理系統(tǒng)中，出現(xiàn)了以下問題：
- 數(shù)據(jù)庫中的ID:
1965951881494065154 - Vue前端接收到的ID:
1965951881494065200 - 結(jié)果: 修改操作失敗，因為前端發(fā)送的ID與數(shù)據(jù)庫中的實際ID不匹配
問題根源分析
JavaScript數(shù)字精度限制
JavaScript中的數(shù)字都是以64位浮點數(shù)存儲的，其中：
- 1位符號位
- 11位指數(shù)位
- 52位尾數(shù)位
這意味著JavaScript能夠安全表示的最大整數(shù)是 2^53 - 1 = 9007199254740991，即 Number.MAX_SAFE_INTEGER。
雪花算法ID的特點
現(xiàn)代分布式系統(tǒng)中常用的雪花算法(Snowflake)生成的ID通常是19位的長整型數(shù)字，如：
1965951881494065154 (19位)
這個數(shù)字遠遠超過了JavaScript的安全整數(shù)范圍，因此在JSON序列化傳輸?shù)角岸藭r會發(fā)生精度丟失。
解決方案
核心思路
將Long類型的ID在JSON序列化時轉(zhuǎn)換為字符串，避免JavaScript的數(shù)字精度問題。
使用Jackson的ToStringSerializer
在Java實體類中，對ID字段添加 @JsonSerialize(using = ToStringSerializer.class) 注解。
實施步驟
1. 添加必要的導入
在實體類中添加Jackson相關(guān)的導入：
import com.fasterxml.jackson.databind.annotation.JsonSerialize; import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;
2. 在ID字段上添加注解
/** 服務(wù)器ID */ @JsonSerialize(using = ToStringSerializer.class) private Long id;
3. 完整的實體類示例
package com.ruoyi.email.domain;
import java.io.Serializable;
import java.util.Date;
import javax.validation.constraints.*;
import com.baomidou.mybatisplus.annotation.FieldFill;
import com.baomidou.mybatisplus.annotation.TableField;
import com.baomidou.mybatisplus.annotation.TableName;
import com.fasterxml.jackson.annotation.JsonFormat;
import com.fasterxml.jackson.databind.annotation.JsonSerialize;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;
import com.ruoyi.common.annotation.Excel;
import com.ruoyi.common.annotation.Excel.ColumnType;
import lombok.Data;
import lombok.EqualsAndHashCode;
@Data
@EqualsAndHashCode
@TableName("tbl_email_server")
public class EmailServer implements Serializable
{
private static final long serialVersionUID = 1L;
/** 服務(wù)器ID */
@JsonSerialize(using = ToStringSerializer.class)
private Long id;
// ... 其他字段
}
解決方案的工作原理
序列化過程
- 后端序列化: Long類型的ID
1965951881494065154被序列化為字符串"1965951881494065154" - 前端接收: JavaScript接收到字符串格式的ID，不會有精度丟失
- 前端發(fā)送: 前端將字符串ID發(fā)送回后端
- 后端反序列化: Spring Boot自動將字符串轉(zhuǎn)換回Long類型
JSON數(shù)據(jù)格式對比
修改前:
{
"id": 1965951881494065200, // 精度丟失！
"serverCode": "EMAIL_001",
"name": "主郵件服務(wù)器"
}
修改后:
{
"id": "1965951881494065154", // 字符串格式，精度保持！
"serverCode": "EMAIL_001",
"name": "主郵件服務(wù)器"
}
前端處理注意事項
HTML模板中的處理
由于ID現(xiàn)在是字符串格式，在前端模板中可以正常使用：
<template>
<el-table :data="serverList">
<el-table-column prop="id" label="ID" />
<el-table-column label="操作">
<template #default="{ row }">
<!-- 字符串ID可以直接使用 -->
<el-button @click="editServer(row.id)">編輯</el-button>
</template>
</el-table-column>
</el-table>
</template>
JavaScript中的處理
// 接收數(shù)據(jù)
const serverData = {
id: "1965951881494065154", // 字符串格式
serverCode: "EMAIL_001",
name: "主郵件服務(wù)器"
};
// 發(fā)送請求
updateEmailServer({
id: serverData.id, // 直接使用字符串ID
serverCode: "EMAIL_002"
});
驗證結(jié)果
修改完成后，驗證效果：
- 數(shù)據(jù)庫ID:
1965951881494065154 - 前端接收ID:
"1965951881494065154"(字符串格式) - 前端發(fā)送ID:
"1965951881494065154" - 后端接收ID:
1965951881494065154(自動轉(zhuǎn)換為Long)
結(jié)果: ID數(shù)據(jù)在前后端傳輸過程中保持完全一致，修改操作成功！
適用場景
這個解決方案適用于以下情況：
- 雪花算法生成的ID: 通常是18-19位的長整型
- 時間戳ID: 毫秒級時間戳生成的長整型ID
- 其他超過JavaScript安全范圍的Long類型字段: 如訂單號、交易流水號等
性能影響
- 序列化性能: 幾乎無影響，字符串序列化很高效
- 網(wǎng)絡(luò)傳輸: 略微增加傳輸字節(jié)數(shù)（引號）
- 前端處理: 字符串比較操作性能略優(yōu)于數(shù)字比較
其他解決方案對比
方案一：前端使用BigInt
// 需要特殊處理
const id = BigInt("1965951881494065154");
缺點: 需要修改大量前端代碼，兼容性問題
方案二：自定義JSON配置
@Configuration
public class JacksonConfig {
@Bean
public Jackson2ObjectMapperBuilder jackson2ObjectMapperBuilder() {
return new Jackson2ObjectMapperBuilder()
.simpleDateFormat("yyyy-MM-dd HH:mm:ss")
.serializerByType(Long.class, ToStringSerializer.instance);
}
}
缺點: 影響全局所有Long類型字段
方案三：使用@JsonSerialize注解
@JsonSerialize(using = ToStringSerializer.class) private Long id;
優(yōu)點:
- 精確控制，只影響特定字段
- 無需修改前端代碼
- 性能影響最小
- 代碼清晰易維護
總結(jié)
通過在Java實體類的ID字段上添加 @JsonSerialize(using = ToStringSerializer.class) 注解，我們成功解決了JavaScript大數(shù)精度丟失的問題。這個方案具有以下優(yōu)勢：
- 簡單易實施: 只需添加一個注解
- 影響范圍小: 只影響特定字段，不會波及其他功能
- 兼容性好: 前端代碼無需修改
- 性能優(yōu)秀: 幾乎無性能損耗
這個問題在現(xiàn)代Web開發(fā)中非常常見，特別是在使用分布式ID生成算法的系統(tǒng)中。掌握這個解決方案能夠幫助開發(fā)者快速解決類似的精度丟失問題，提高系統(tǒng)的穩(wěn)定性和數(shù)據(jù)準確性。
以上就是JavaScript大數(shù)ID精度丟失問題的解決方案的詳細內(nèi)容，更多關(guān)于JavaScript大數(shù)ID精度丟失的資料請關(guān)注腳本之家其它相關(guān)文章！
相關(guān)文章
JavaScript實現(xiàn)圖片自動加載的瀑布流效果
這篇文章主要介紹了JavaScript實現(xiàn)圖片自動加載的瀑布流效果的相關(guān)資料,需要的朋友可以參考下2016-04-04
這篇文章主要為大家詳細介紹了基于javascript實現(xiàn)移動端上的觸屏拖拽功能，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2016-03-03
這篇文章主要為大家詳細介紹了原生JS實現(xiàn)登錄框郵箱提示，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2021-10-10
JavaScript+canvas實現(xiàn)五子棋游戲
這篇文章主要為大家詳細介紹了JavaScript+canvas實現(xiàn)五子棋游戲，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2022-05-05
這篇文章主要為大家詳細介紹了js布局實現(xiàn)單選按鈕控件，文中示例代碼介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們可以參考一下2020-01-01
高性能web開發(fā) 如何加載JS，JS應(yīng)該放在什么位置？
所有瀏覽器在下載JS的時候，會阻止一切其他活動，比如其他資源的下載，內(nèi)容的呈現(xiàn)等等。至到JS下載、解析、執(zhí)行完畢后才開始繼續(xù)并行下載其他資源并呈現(xiàn)內(nèi)容。2010-05-05
背景：很久之前就在marry5.com看到這個效果，當時覺得很神奇，礙于水平有限，沒做出來。2008-09-09
自己做一個通用的控件，雖然不是絕對通用啦，但在我這個項目里還是可以隨意調(diào)用的，思想的話也可以借鑒到別的項目中2014-05-05
這篇文章主要介紹了antd?table長表格如何出現(xiàn)滾動條,本文通過實例代碼給大家介紹的非常詳細，對大家的學習或工作具有一定的參考借鑒價值，需要的朋友可以參考下2022-06-06
本文主要介紹了如何用javascript判斷dom是否有存在某class的值。具有很好的參考價值，下面跟著小編一起來看下吧2017-02-02