javascript引入bigint是为了解决number类型无法安全表示超大整数的问题，1 bigint能表示任意精度的整数，避免超出number.max_safe_integer导致的精度丢失；2 创建方式包括加n后缀或使用bigint()构造函数；3 支持常规算术和位运算，但除法结果会截断小数部分；4 与number不可直接混合运算，需显式转换；5 比较时宽松相等会类型转换，严格相等不会；6 json序列化需自定义处理；7 不支持math对象方法；8 0n为假值，其他为真值；9 性能上不如number，适用于特定高精度场景。
JavaScript的BigInt类型是ES2020引入的一种新的原始数据类型，它能够表示任意大的整数。这意味着我们不再受限于Number类型所能安全表示的最大整数（Number.MAX_SAFE_INTEGER，即2的53次方减1），可以处理比这个范围更大的整数，而不会丢失精度。
在JavaScript中，使用BigInt并不复杂，但有一些关键点需要注意。
最直接的方式是在整数后面加上一个n后缀来创建BigInt字面量，比如123n。你也可以使用BigInt()构造函数将Number或字符串转换为BigInt，例如BigInt(123)或BigInt("123456789012345678901234567890n")。
立即学习“Java免费学习笔记（深入）”；
BigInt支持所有常规的算术运算符：加法（+）、减法（-）、乘法（*）、除法（/）、求模（%）和幂运算（**）。位运算符（&、|、^、~、、<code>>>、>>>）也同样适用。需要注意的是，BigInt的除法操作会截断小数部分，返回一个整数BigInt，这和Number的浮点数除法有所不同。
在比较方面，BigInt可以与Number进行比较，使用==（宽松相等）会进行类型转换，而===（严格相等）则不会，因此123n === 123会是false。BigInt也可以和BigInt之间进行大小比较。
一个重要的细节是，BigInt和Number不能直接混合进行算术运算。例如，10n + 5会抛出一个TypeError。这是为了避免潜在的精度损失问题，强制开发者明确地进行类型转换。如果你需要混合运算，必须先将其中一个操作数转换为与另一个操作数相同的类型。
为什么JavaScript需要BigInt？它解决了哪些实际问题？
说实话，作为一名开发者，我个人觉得BigInt的出现，简直是解决了一个长久以来的痛点。你可能遇到过这样的场景：处理一些ID，或者进行加密计算，或者在一些金融应用中，突然发现你的数字超出了Number.MAX_SAFE_INTEGER，然后，精度问题就像幽灵一样出现了。
JavaScript的Number类型是基于IEEE 754双精度浮点数标准实现的。这个标准设计之初是为了兼顾整数和浮点数，但它有一个固有的限制：它只能精确表示介于-2^53和2^53之间的整数。一旦你超出了这个范围，比如尝试表示一个非常大的数据库ID，或者一个加密哈希值，你就会发现数字的末尾开始变得不准确，原本应该是唯一的ID，结果却可能和另一个ID一样，或者计算结果莫名其妙地错了。这可不是闹着玩的，尤其是在涉及金钱或者敏感数据的应用里，这种不确定性简直是噩梦。
BigInt的引入，就是为了填补这个空白。它让JavaScript能够原生支持任意精度的整数运算。这意味着我们可以安全地处理那些超长的数字串，比如区块链中的交易哈希、高精度的时间戳、科学计算中遇到的巨大数值，甚至是那些几十位长的商品批次号。在我看来，它不是一个日常使用的类型，但它在特定领域，比如Web3、金融后端数据处理、或任何需要处理巨型整数的场景下，是不可或缺的。它提供了一种可靠的方式来确保数据的完整性，避免了因为语言底层限制而导致的潜在错误。
BigInt与其他数据类型交互时有哪些常见的陷阱和注意事项？
BigInt的设计哲学，我觉得是“安全第一”，所以它在与其他数据类型交互时，显得有些“固执”，这也就导致了一些常见的陷阱。
一个最让我印象深刻的“坑”就是BigInt和Number不能直接混合运算。比如你写了10n + 5，它不会像其他弱类型语言那样自动帮你转换，而是直接抛一个TypeError。这背后的逻辑其实是好的，因为如果允许隐式转换，那么在Number精度不足以表示BigInt时，就会发生静默的数据丢失，这比一个明确的错误要糟糕得多。所以，当你需要将BigInt与Number一起使用时，你必须手动进行类型转换，要么把Number转成BigInt（10n + BigInt(5)），要么把BigInt转成Number（Number(10n) + 5），但后者要小心精度问题。
另一个需要注意的地方是JSON.stringify()。如果你尝试直接序列化一个包含BigInt的JavaScript对象，你会发现它会抛出TypeError: Do not know how to serialize a BigInt。这是因为JSON标准本身没有BigInt这种数据类型。解决办法通常是提供一个自定义的replacer函数，将BigInt转换为字符串，例如：
JSON.stringify(obj, (key, value) => {
return typeof value === 'bigint' ? value.toString() : value;
});反过来，解析时也需要特别处理，因为解析回来后它就变成了一个字符串，而不是BigInt了。
还有，Math对象的方法，比如Math.max()、Math.min()、Math.abs()等，都不支持BigInt。如果你想对BigInt进行这些操作，你需要自己实现或者找到相应的库函数，因为Math对象是为Number类型设计的。这在使用时确实会让人感到不便，但考虑到BigInt的任意精度特性，重新实现这些函数也是可以理解的。
最后，布尔上下文中的BigInt行为也值得一提。0n被认为是假值（falsy），而所有其他BigInt值（包括负数）都是真值（truthy）。这和Number的0是假值，其他非零数是真值是一致的。
使用BigInt对性能有何影响？未来它会如何发展？
谈到BigInt的性能，我个人的经验是，它肯定不如原生的Number类型快。这不是因为BigInt实现得不好，而是由它的本质决定的：它要处理任意大的整数，这意味着它不能像固定大小的Number那样，直接利用CPU底层的算术逻辑单元（ALU）进行单周期操作。BigInt的运算通常涉及到模拟长整数的算术，这需要更多的CPU周期和内存分配。
举个例子，一个简单的BigInt加法，可能需要在内部进行多位数的加法运算，这比两个Number的加法复杂得多。所以，如果你的应用场景不需要处理超出Number.MAX_SAFE_INTEGER范围的数字，那么坚持使用Number是更明智的选择，因为它的性能优势是显而易见的。BigInt是为解决精度问题而生的，而不是为了提升通用整数运算的性能。在内存方面，一个非常大的BigInt也会比一个Number占用更多的内存，因为它的存储大小是动态的，取决于数字的位数。
至于BigInt的未来发展，我觉得它会变得越来越重要，尤其是在Web技术栈中。随着区块链、WebAssembly、加密货币等领域的发展，对大整数计算的需求只会增多。
未来，我预想会有更多标准库和API开始原生支持BigInt，减少我们手动转换的麻烦。比如，WebAssembly现在已经有了BigInt的支持，这意味着在高性能计算场景下，JavaScript和WebAssembly之间传递大整数会更加顺畅。同时，可能会有更多的第三方库和框架，在底层对BigInt进行优化和封装，让开发者在使用时感知不到太多性能上的差异，或者至少能够更容易地管理这些差异。
在我看来，BigInt已经很好地填补了JavaScript在数值处理上的一个关键空白。它不会成为日常编程的主角，但它在那些需要绝对精度和处理巨型整数的特定领域，会持续发挥其不可替代的作用。它代表了JavaScript在向更广阔、更复杂的计算领域迈进的决心。
