為什么最后一個數(shù)字變了？

Number類型統(tǒng)一按浮點數(shù)處理，使用64位二進制位進行存儲，如下圖所示：

其中有1位符號位，11位指數(shù)位，52位有效數(shù)字位，IEEE754規(guī)定，有效數(shù)字第一位默認總是1，即有效數(shù)字總是1.xx...xx的形式，其中第一位不進行存儲，而xx..xx的部分保存在64位浮點數(shù)之中，最長可能為52位。因此，JavaScript實際提供的有效數(shù)字最長為53個二進制位，一個數(shù)字可以表示為：

(-1)^符號位 * 1.xx...xx * 2^指數(shù)位

有效數(shù)字精度最多只能到53個二進制位，這意味著，絕對值小于2的53次方的整數(shù)，即在-（Math.pow(2, 53) - 1）到 Math.pow(2, 53) - 1范圍內(nèi)的整數(shù)都可以精確表示（安全整數(shù)），而不在該范圍內(nèi)的整數(shù)則會喪失精度。

es6中增加了Number.MAX_SAFE_INTEGER及Number.MIN_SAFE_INTEGER來表示安全整數(shù)范圍的上下限，還增加了方法Number.isSafeInteger來判斷是否處于安全整數(shù)范圍內(nèi)。

你代碼中的值明顯已經(jīng)超過這個范圍了，所以喪失精度了，出現(xiàn)不可預料的情況，這么大的數(shù)字不適合用Number類型

溢出了吧，這么長的還是用字符串吧，銀行卡號一般不會用數(shù)字類型

所有ID性質(zhì)的數(shù)據(jù)都應該用字符串模式，即使全是數(shù)字也不能用數(shù)字。否則處理中很容易出現(xiàn)問題。

最大安全整數(shù)：Number.MAX_SAFE_INTEGER（es6） === Math.pow(2,53)

1、JS中只有一種類型數(shù)，即64位（1bit 的符號位，11bits 的指數(shù)部分 ，以及52bits 的小數(shù)部分）雙精度浮點數(shù)，當整數(shù)數(shù)值過大時，就會發(fā)生精度丟失。
2、所謂安全整數(shù)即能夠唯一確定的數(shù)字，即能夠使用64位二進制數(shù)唯一確定的整數(shù)?？紤]2^53，轉(zhuǎn)換成對應表示方式后其小數(shù)部分總共包括53位，發(fā)生了精度丟失，所以在JS中無法區(qū)別2^53與2^53+1;
3、安全整數(shù)與JS是否能夠正確進行運算關(guān)系密切，當運算數(shù)與運算結(jié)果都處于安全整數(shù)的范圍內(nèi)時，才能保證JS運算結(jié)果正確。

超過最大值了吧 用字符串吧

超過最大值了，轉(zhuǎn)換成字符串類型吧

這里應該是超過數(shù)字的最大值了，銀行卡號一般存的不都是字符串嗎？這個卡號是你們后臺傳給你的還是你從用戶輸入得到的

Number.MAX_SAFE_INTEGER
// 9007199254740991

超過這個值的數(shù)就不安全了，如果不參與計算就用文本保存吧