javascript处理大整数的核心是bigint类型，它解决了number类型精度丢失的问题。1. bigint通过在整数后加n定义，如123n；2. 使用bigint()构造函数转换数值或字符串；3. 支持算术和位运算但不能与number混合运算；4. 比较操作允许与number比较但严格相等区分类型；5. 不能用于math对象的函数；6. json序列化需手动转为字符串并在反序列化时恢复；7. 常见于数据库id、加密货币、金融计算和科学计算场景。
JavaScript处理大整数，核心就是使用BigInt类型。它能安全地表示任意精度的整数，远超Number类型所能承载的范围，彻底解决了JavaScript在处理大型数字时精度丢失的痛点。就这么简单？但这里面可不止是数字后面加个n那么简单，还有不少细节和“坑”需要注意。
BigInt的引入，直接提供了一种原生的方式来定义和操作超出Number.MAX_SAFE_INTEGER（即2^53 – 1）的整数。你只需在整数后面加上一个n后缀，比如123n，它就是一个BigInt。如果你想把一个Number类型或者字符串转换成BigInt，可以使用BigInt()构造函数，例如BigInt(123)或BigInt(“12345678901234567890”)。
操作上，BigInt支持加、减、乘、除、取模等基本算术运算，以及位运算。但这里有个很重要的规则：BigInt不能和Number类型混合运算。如果你尝试10n + 5，JavaScript会抛出一个TypeError。这种严格性，我觉得是深思熟虑的结果，它强制开发者在处理大数时保持类型一致性，避免了隐式的、可能导致错误的结果的类型转换。比较操作符（如==、>、
立即学习“Java免费学习笔记（深入）”；
BigInt与Number类型的主要区别是什么？
要真正用好BigInt，理解它和传统Number类型之间的核心差异至关重要。这不仅仅是数值范围的问题，更是设计哲学上的不同。
首先，最直观的就是数值范围。Number类型在JavaScript中是双精度浮点数，它能安全表示的整数范围是有限的，大约在正负9千万亿（Number.MAX_SAFE_INTEGER）。一旦超出这个范围，整数的精度就会开始丢失，比如9007199254740992 + 1可能会得到9007199254740992，而不是你期望的9007199254740993。BigInt则没有这个限制，理论上它可以表示任意大的整数，只要你的系统内存允许。这对我来说，是它存在的根本原因。
其次是类型转换和混合运算。前面提到过，BigInt和Number不能直接进行算术混合运算。这意味着如果你从后端拿到一个BigInt格式的ID，想和前端某个Number类型的计数器相加，你必须显式地将其中一个转换成另一个类型。比如，BigInt(someNumber) + anotherBigInt。这种显式转换的必要性，在我看来，是JavaScript在类型安全方面的一个进步，它避免了可能导致静默错误的隐式类型转换。
再来就是与Math对象的兼容性。Math对象中的所有函数，比如Math.floor()、Math.pow()、Math.sqrt()等，都是为Number类型设计的，它们不接受BigInt作为参数。如果你需要对BigInt进行类似数学函数的复杂操作，你得自己想办法，或者找个专门处理BigInt的库。这表明BigInt的设计初衷就是纯粹的整数运算，而不是通用的数学计算。
最后，一个非常常见的“坑”是JSON序列化。JSON.stringify()默认不支持BigInt。如果你尝试序列化一个包含BigInt值的对象，它会抛出一个TypeError。这需要你手动处理，通常是在序列化前将BigInt转换为字符串。
在实际项目中，BigInt的常见使用场景有哪些？
BigInt的出现，填补了JavaScript在处理大整数时的空白，让它在很多以前需要借助第三方库或者牺牲精度的场景下，变得更加得心应手。
一个非常典型的场景是处理数据库中的大整数ID。很多分布式系统或者大型数据库，会生成非常长的ID，比如Snowflake ID，这些ID往往超过了JavaScript Number的安全整数限制。当这些ID从后端传到前端时，如果不使用BigInt，就可能导致ID值不匹配或者在进行比较时出现问题。我遇到过不少次因为ID精度丢失导致前端数据错乱的情况，BigInt就是解决这个问题的利器。
另一个重要领域是加密货币和区块链应用。在这些场景中，交易金额、区块高度、哈希值等数据，往往都是非常大的整数。例如，比特币的最小单位是satoshi，一个比特币是10的8次方satoshi，处理多比特币的交易时，金额很容易就超出Number的安全范围。BigInt在这里是不可或缺的，它保证了这些敏感数值的精确性。
此外，高精度金融计算的某些方面也能用到BigInt。虽然涉及到小数的金融计算通常推荐使用专门的十进制库来避免浮点数精度问题，但对于纯整数的大额交易或某些特定计算，BigInt能够确保整数部分的绝对精度。比如，计算一个非常大本金的复利，如果年数和利率使得总金额的整数部分变得极大，BigInt就能派上用场。
最后，在科学计算和大数据处理中，当需要处理超出常规Number范围的计数、排列组合、大数阶乘等场景时，BigInt提供了一个原生的、高性能的解决方案。它让JavaScript在这些领域也能进行更深层次的数值计算。
如何处理BigInt与JSON序列化和反序列化的问题？
说实话，这JSON序列化的问题，我刚接触BigInt的时候也踩过坑。JSON.stringify()默认不支持BigInt，这是因为JSON标准本身并没有定义一个对应任意精度整数的类型。所以，当你试图序列化一个包含BigInt值的对象时，你会得到一个TypeError。解决这个问题，通常需要一些手动转换。
最常见的做法是利用JSON.stringify()的第二个参数——replacer函数，在序列化时将BigInt值转换为字符串。
序列化（BigInt到JSON字符串）：
const dataWithBigInt = {
id: 123456789012345678901234567890n, // 这是一个BigInt
name: "大型数据项",
amount: 5000000000000000000n,
details: {
timestamp: 167888888888888888888n
}
};
const jsonString = JSON.stringify(dataWithBigInt, (key, value) => {
// 检查当前值是否为BigInt类型
if (typeof value === 'bigint') {
// 将BigInt转换为字符串，并可选地添加一个后缀标识，方便反序列化时识别
// 比如 'n' 或者直接返回 value.toString()
return value.toString() + 'n'; // 我个人喜欢加个'n'来明确标识
}
return value; // 对于非BigInt类型，正常返回
});
console.log(jsonString);
// 输出示例: {"id":"123456789012345678901234567890n","name":"大型数据项","amount":"5000000000000000000n","details":{"timestamp":"167888888888888888888n"}}
这里，我们定义了一个replacer函数。当JSON.stringify遍历对象时，如果遇到一个bigint类型的值，它会调用这个函数，然后我们把BigInt转换成字符串并加上一个’n’后缀。这个后缀是一个自定义的约定，用来在反序列化时识别并转换回BigInt。
反序列化（JSON字符串到BigInt）：
相应的，当你要把这个JSON字符串解析回JavaScript对象时，你需要使用JSON.parse()的第二个参数——reviver函数。
const parsedObject = JSON.parse(jsonString, (key, value) => {
// 检查当前值是否为字符串，并且符合我们之前定义的BigInt字符串模式
// 比如以数字开头，以'n'结尾
if (typeof value === 'string' && /^\d+n$/.test(value)) {
// 移除'n'后缀，并使用BigInt()构造函数将其转换回BigInt类型
return BigInt(value.slice(0, -1));
}
return value; // 对于不符合模式的值，正常返回
});
console.log(parsedObject.id);
console.log(typeof parsedObject.id); // 输出: bigint
console.log(parsedObject.amount);
console.log(typeof parsedObject.amount); // 输出: bigint
通过这个reviver函数，我们检查每个字符串值。如果它匹配我们之前序列化时添加的’n’后缀模式，我们就把它转换回BigInt。这种模式虽然需要手动编写replacer和reviver，但它是目前处理BigInt JSON序列化的标准且最可靠的方法。在一些大型项目中，你可能会把这部分逻辑封装成一个通用的JSON处理工具函数，或者利用一些库来简化操作。
暂无评论内容