前言：昨晚上和後端對介面，乙個返回的json陣列裡面，有兩條資料一直對不上號。他在postman裡面測是乙個資料，到了我這邊拿到資料以後console.log，那個引數的資料值就變了。一直到不到原因
但是在前端response裡面可以看到，後端傳的資料是正確的，在preview裡面卻不正確：
2. 原因： js 解析 json 資料時，對於 long 型別資料長度有限制。此時的 long 型別資料 fileid 長度超限，jsp 中解析時出現精度丟失，導致資料值出現誤差。
3. 解決： 修改返回資料 long 型別為 string 型別，作為字元處理。
這是後端修改後的fileid，他在後端轉化成字串型別
解決這個問題還是看了下面這篇文章
後端傳Long型別資料精度問題
在今天編碼過程中發現乙個小問題。後端資料庫資料 1169459812992421888 前台拿到 1169459812992422000 前幾位高度重合，排除程式邏輯問題。在返回前設定斷點列印，資料依據與資料庫依舊保持一致 說明資料是在返回過程中丟失了精度。考慮不直接傳long，傳json 引入依賴...
前端處理後端傳回的 Long 型別資料精度丟失
直接拋問題，如下圖所示 檢視 network 時，響應回來的 long 型別資料和在控制台列印的資料出現的精度丟失的問題。經查閱資料，原來 js 內建有 32 位整數，而 number 型別的安全整數是 53 位。如果超過 53 位，則精度會丟失。正如現在後台傳來乙個 64 位的 long 型別整數...
在介面傳參時，前端的資料型別對應後端的資料型別
c 裡int是有大小的,預設的int最大是20億多,有時候用不著這麼大的數字,就發明了小整數,從小到大分別是byte short int long，其中,預設的是帶符號的,就是可正可負,如果前面加上u,就代表無符號的,就是正數,如果是u開頭的,因為沒有負數部分,所以正數部分可以是原來的兩倍大小 sb...