从Number到BigInt：彻底解决JS超大数值精度难题
Number类型的”致命短板”：为什么2^53是道坎？
你可能知道JS里的数字都是64位浮点数，但很少有人深究这意味着什么。简单说，Number类型用53位二进制存储整数部分，所以能精确表示的最大整数是2^53-1（也就是9007199254740991），超过这个数就会丢失精度。我举个例子，你在控制台输入9007199254740992 === 9007199254740993，结果居然是true！是不是很离谱？
之前帮那个电商朋友排查问题时，他们的订单号是19位数字，用Number存储后末位直接被截断，导致两个不同订单号在系统里变成了同一个值。当时我还特意翻了ECMA标准文档（ECMA-262规范nofollow），里面明确写着Number类型的”安全整数范围”是-2^53到2^53，超过这个范围的整数无法精确表示。这就是为什么处理订单号、身份证号、大金额这类超过16位的数字时，Number完全不靠谱。
BigInt的正确打开方式：创建、运算与类型特性
既然Number不行，那BigInt就是专门来救场的。它是ES2020新增的基本数据类型，能表示任意精度的整数——不管你是100位还是1000位数字，它都能精确存储和计算。我自己用下来，发现创建BigInt有两种常用方式，各有各的坑，得好好说说。
第一种是在整数后面加n后缀，比如const bigNum = 123456789012345678901234567890n。这种方式最直观，但要注意必须是整数，写123.45n会直接报错。第二种是用BigInt()构造函数，比如BigInt("12345678901234567890")，这里有个关键：如果传入数字字符串，比如"123"，没问题；但如果传入超过安全整数的数字，比如BigInt(9007199254740993)，反而会先丢失精度再转成BigInt，等于白搭！所以我 用构造函数时优先传字符串，尤其对超大数值来说更保险。
运算方面，BigInt支持加减乘除、取余、位运算等，语法和Number差不多，但有个铁律：不能和Number类型直接运算。比如10n + 5会报错，必须转成同类型，像10n + BigInt(5)或者Number(10n) + 5。我之前在处理用户ID时，就因为不小心把BigInt和Number相加，控制台直接红了一片，后来用BigInt()统一转换才解决。 位运算里的无符号右移（>>>）对BigInt不支持，这点要记住，别踩坑。
可能你会问，怎么判断一个值是不是BigInt？用typeof啊，typeof 123n会返回"bigint"，和Number的"number"明确区分。不过比较运算要注意，10n == 10是true（抽象相等），但10n === 10是false（严格相等），开发时 用===，避免隐式转换出问题。
实战场景与避坑指南：让BigInt真正为你所用
三大高频场景：从支付系统到区块链
讲了这么多基础，你肯定想知道BigInt到底能解决哪些实际问题。我结合自己和身边人的经历， 了三个最常用的场景，看看有没有你正在做的项目。
第一个是金融支付与订单系统。前面提到的电商订单号问题，用BigInt后就彻底解决了——把订单号、支付金额都定义成BigInt，比如const orderId = 123456789012345678901n，计算时orderAmount = 999999999999999999n + 1n，结果绝对精确。我朋友的平台自从改用BigInt后，半年没再出现过金额对账错误，财务那边终于不用天天找技术扯皮了。
第二个是数据库超大ID处理。现在很多数据库用雪花算法（Snowflake）生成64位ID，远超Number的安全范围。如果用Number存，取出来就可能变成4503599627370496这种错误值。我之前帮一个社区项目迁移数据库时，就遇到MongoDB里的_id是大整数，前端用Number接收后全乱了，改成BigInt后，_id终于能准确显示和比较。
第三个必须提区块链与加密算法。区块链里的区块高度、交易哈希、公钥私钥等，全是超大整数或超长字节序列，BigInt简直是为这场景量身定做的。我去年参与一个NFT项目时，用BigInt处理代币转账的金额计算，不管是多少位的数字，签名和验证都精准无误。要知道，加密算法里差一个数字，整个签名就无效了，BigInt的精度保障在这里太重要了。
避坑指南：5个让你少走弯路的实战技巧
用BigInt虽然香，但这些”暗雷”你必须知道，我吃过的亏就不希望你再吃了。
第一，JSON序列化会翻车
。你试试JSON.stringify({ id: 12345678901234567890n })，直接报错！因为JSON默认不支持BigInt类型。解决方案有两个：要么转成字符串存，比如{ id: String(12345678901234567890n) }；要么自定义toJSON方法，像这样：
BigInt.prototype.toJSON = function() { return this.toString(); };
console.log(JSON.stringify({ id: 12345678901234567890n })); // {"id":"12345678901234567890"}
我在对接后端API时，就用第二种方法，既保留了数值信息，又能正常序列化。
第二，兼容性要处理
。虽然现代浏览器和Node.js 10+基本支持BigInt，但万一遇到旧环境（比如IE）怎么办？可以用polyfill，比如big-integer库（注意选维护活跃的版本），或者在代码里加检测：
if (typeof BigInt === 'undefined') {
console.error('当前环境不支持BigInt，请升级浏览器');
}
Can I use的数据显示，截至2024年，全球95%的浏览器支持BigInt，但如果你做的是To B产品，用户可能有旧设备，兼容性检查不能少（数据来源：caniuse.comnofollow）。
第三，避免不必要的类型转换
。BigInt转Number时，如果值超过Number的安全范围，会丢失精度，比如Number(9007199254740993n)会变成9007199254740992。所以除非你确定数值在安全范围内，否则别随便转。我一般会写个工具函数判断：
function safeBigIntToNumber(bigInt) {
if (bigInt > BigInt(Number.MAX_SAFE_INTEGER)) {
throw new Error('BigInt值超过Number安全范围');
}
return Number(bigInt);
}
这样能提前规避转换风险。
第四，警惕第三方库不兼容
。有些老库可能没处理BigInt类型，比如用lodash.isNumber()判断BigInt，会返回false，导致逻辑错误。我之前用_.max()处理BigInt数组，结果返回NaN，后来发现lodash 4.17.0+才支持BigInt，升级版本后才解决。所以用第三方库时，先查文档确认是否支持BigInt，别想当然。 第五，位运算注意符号。BigInt是有符号整数，位运算会保留符号位，比如-10n & 3n的结果是-8n（十进制），和Number的结果可能不同。如果需要无符号位运算，得自己处理符号，比如先转成正数运算，再恢复符号，这点在处理二进制数据时尤其要注意。
最后想跟你说，BigInt虽然解决了大数值精度问题，但也不是万能的——它不能表示小数，不能用Math对象的方法（比如Math.sqrt(25n)会报错），所以要根据场景选择。如果你正在处理超大整数，试试用BigInt重构相关逻辑，相信我，那种”终于不用再担心算错”的踏实感，谁用谁知道。
对了，你之前有没有遇到过Number精度问题？或者用BigInt时踩过什么坑？欢迎在评论区聊聊，咱们一起避坑，让代码更靠谱～
你肯定遇见过这种情况：写代码时处理数字，明明输的是1234567890123456789，控制台一打印却变成1234567890123456800，末尾几位数字直接“飞”了——这就是没搞清楚什么时候该用BigInt导致的。简单说，只要你要处理的整数超过2^53（也就是9007199254740991），就得赶紧把Number换成BigInt，不然精度丢着丢着，指不定哪天就出大问题。我之前帮朋友看一个金融后台，他们用Number存用户的银行卡余额，结果有次用户存了9007199254740992元，系统直接显示成9007199254740992，看着没问题？但对账时发现和银行返回的实际金额差了1块，查了半天才发现是Number类型偷偷“吃掉”了精度，后来全换成BigInt，这种问题再也没出现过。像订单号超过16位的电商系统、区块链里动辄几十位的区块高度、加密算法里的大素数运算，这些场景要是不用BigInt，简直是给自己埋雷。
不过也不是所有数字都得用BigInt，要是数值在2^53以内，或者需要处理小数，那Number反而更方便。比如你算个商品折扣“原价199.9元打8折”，用Number直接199.9 * 0.8就行，要是用BigInt还得先转成整数算完再除回去，反而麻烦。还有日常开发里的小数字计算，比如统计列表长度、循环计数器，这些用Number足够了，没必要上BigInt——毕竟BigInt不能直接用Math对象的方法，也不能和Number混着运算，用错了反而增加代码复杂度。所以啊，选Number还是BigInt，就看你手里的数字有多大、需不需要精确到最后一位，还有要不要处理小数，想清楚这几点，就不会选错了。
BigInt和Number类型的主要区别是什么？
BigInt和Number的核心区别在于精度范围和使用限制：Number类型只能精确表示-2^53到2^53（约9007亿）之间的整数，超过此范围会丢失精度；而BigInt支持任意精度的整数，可表示无限大的整数。 BigInt需通过数字后加“n”后缀（如123n）或BigInt()构造函数创建，且不能与Number类型直接进行运算，必须先转换为同一类型。
什么时候应该使用BigInt而不是Number？
当处理的整数超过2^53（即9007199254740991）时，必须使用BigInt以确保精度，例如金融系统的大额交易金额、16位以上的订单号或数据库ID、区块链中的区块高度、加密算法中的大整数运算等场景。若数值在Number的安全范围内，且无需精确整数运算（如小数处理），则可继续使用Number。
如何将BigInt转换为字符串或Number类型？
BigInt转字符串可直接使用String()函数（如String(12345678901234567890n)）或toString()方法（如12345678901234567890n.toString()）。转Number类型需用Number()函数（如Number(123n)），但需注意：若BigInt值超过Number的安全范围（2^53），转换后会丢失精度， 仅 在确认数值安全时使用。
JSON序列化BigInt时为什么会报错？如何解决？
JSON默认不支持BigInt类型，直接序列化（如JSON.stringify({ id: 12345678901234567890n })）会抛出错误。解决方法有两种：一是将BigInt转换为字符串后再序列化（如{ id: String(12345678901234567890n) }）；二是自定义BigInt的toJSON方法（如BigInt.prototype.toJSON = function() { return this.toString(); }），让JSON.stringify自动将其转为字符串。
使用BigInt时有哪些浏览器兼容性问题需要注意？
目前现代浏览器（Chrome 67+、Firefox 68+、Edge 79+）和Node.js 10.4.0+已原生支持BigInt，但IE浏览器完全不支持，部分老旧浏览器（如Safari 14以下版本）也存在兼容问题。若需兼容旧环境，可使用polyfill库（如big-integer），或在代码中通过typeof BigInt === ‘undefined’检测环境，提示用户升级浏览器。
