我的朋友已經工作了 3?年，他過去一直擔任前端工程師。

不幸的是，他被老板批評了，因為他在工作中犯了一個錯誤，這是一個非常簡單但容易忽視的問題，我想也是很多朋友容易忽視的一個問題。

今天我把它分享出來，希望能夠幫助到你，也希望大家遇到這個情況時，不要再放這個錯誤。

錯誤的描述

問題可能是這樣的，Lily在公司負責一個重大項目，其中一個模塊是顯示一條與數字相關的信息，這是后端工程師界面返回的信息（僅舉例）

@RestController
@RequestMapping("/getInfo")
public class YupiTestController {@GetMappingpublic Long getNum() {return 123456789123456789L;}   
}

各位小伙伴，我們調用getInfo接口會返回什么信息呢？會是 123456789123456789 嗎？

通過chrome瀏覽器的調試工具可以看到，似乎一切都和我們想象的一樣，結果是123456789123456789。

但是，頁面顯示的結果是123456789123456780，最后一位是0而不是9。

這到底是怎么回事？這太奇怪了，是不是有點崩潰。

分析出現問題的原因

現在，我們一起來分析一下原因。

我嘗試分析返回的數字，發現只有當數字超過16位時才會出現最后幾位不一致的問題。

是不是因為數字太大，出現了精度損失？

Java語言中的Long類型是64位的，JavaScript語言中的Long類型是小于64位的嗎？

天哪，JavaScript 似乎沒有 Long 類型的數據！

實際上，在 JavaScript 中，我們使用 Number 來表示類型 number 的值。

Number 類型的總長度為 64 位。64位大致就是這樣分配的，其中53位代表小數位，10位代表指數位，1位代表符號位。因此，Number 整數的表示范圍為 -2^53 ~ 2^53。

讓我們嘗試在控制臺上輸出 JavaScript 中的最大值和最小值。

在其他語言中，例如 Java，Long 類型占用 64 個二進制位，最大值為 9223372036854774807 (2?3 — 1)，長度約為 19 位。

在 JavaScript 中，由于 Number 類型的值也包含小數，所以最大值為 9007199254740993 (2^53 - 1)，長度約為 16 位。

所以當Java向JSON返回16位以上的Long類型字段時，前端JavaScript獲取的數據會因為溢出而失去精度。

如何解決這個問題呢？

也許我們可以嘗試在前端解決這個問題，但我認為我們應該尋求后端工程師的幫助。

我們應該將可能超出范圍的數字類型（Long）變量轉換為字符串類型（String）。這個是我的個人處理方法。

遇到的問題

但隨后沒過多久，手機報警短信就飛來了。報警的服務器并不是剛剛的 Node 集群，而是『時序數據庫』InfluxDB。

觀察了下機器的內存與 CPU 開銷走勢，可以發現：應用接入后幾小時內，機器的內存持續在上漲，最終造成 OOM，服務不可用。并且在管理后臺上觸發的一條 SQL 查詢，幾乎會耗盡整臺數據庫機器的 CPU 資源。

當時答主內心想的是：“完了，開發了幾個月的產品, 上線后，盡然是這樣的，年終獎沒了不要說，明年回來，肯定要重新找工作了，我不僅坑了自己，還坑了我的主管” ，當時的內心可謂極度惶恐。

解決問題的方式

經歷過一番內心掙扎后，覺得這樣惶恐下去，解決不了問題，然后就冷靜下來，盡可能地去查找時序數據庫 InfluxDB 相關的分享文章，希望能從中找到一些性能瓶頸相關的資料。幸運的是，在餓了么團隊的一次分享中，我找到一點引起問題的線索，然后開始從數據庫表結構設計、計算查詢優化等方面著手，逐步地進行了優化。

你有哪些好的處理方法呢，歡迎在留言分享。