是否有充分的理由不使用 BigInt？
强制
由于 Number 和 BigInt 之间的强制转换会导致精度损失，因此建议仅在合理预期大于 2^53 的值时才使用 BigInt，而不是在这两种类型之间进行强制转换。
据我了解，没有隐式类型强制，只有显式类型转换。 这对我来说似乎不是一个很好的理由。
当我的数字“小”时，我不应该使用 BigInt 吗？我认为没有充分的理由避免它。
【问题讨论】：
BigInt 用于...嗯...大整数。我的意思是大。 2^53 巨大。
标签： javascript
据我了解，没有隐式类型强制，只有显式类型转换。
确实。
当我的数字“小”时，我不应该使用
BigInt吗？我认为没有充分的理由避免它。
我不是BigInt 的重度用户，但我同意您的说法：如果您依赖的整数范围超出Number.MAX_SAFE_INTEGER，那么您绝对应该使用BigInts，对于大以及“小”整数。
其实我猜MDN文档中的免责声明应该换个角度解释：如果你需要大整数，尽量不要使用类型转换，即不要使用Numbers in第一名。
这是MDN文档中建议that other paragraph的方式：
但是，请小心来回强制值，因为
BigInt的精度在被强制为Number时可能会丢失。
【讨论】：
这些不一定是一项建议。它很容易成为两个相互关联的。
仅对合理可能超过 2^53 的整数使用 BigInt。
BigInt 不是通用号码。它专门用于大整数，因此得名。它们最适合用于您期望大整数很可能出现的特定、孤立的情况，这在很大程度上是因为在其他情况下，设计目标（包括防止意外的精度损失）使类型限制性太强而无用。你不能用它们做Math 的东西，你不能混合类型，等等。对于你知道的小于 2^53 的数字，Number 的限制要少得多（阅读：更有用），并且通常更快，更容易使用。
（有关性能差异的示例，请参阅https://jsperf.com/bigint-vs-number/5。最初的测试在 Chrome 中显示了 1% 的差异，但是一旦您的值不是有效恒定的，就很难隐藏差异和性能急剧下降。）
不要在BigInt 和Number 之间转换。
BigInt 的全部意义在于充当任意精度整数。转换为 Number 会占用您要求的所有额外位，并将它们硬塞到双精度浮点数中。只有最重要的 52+1 位将被保留。如果你能容忍这种情况发生，你可能一开始就不需要BigInt。
它们是相互关联的，因为与BigInts 打交道的次数越多，转换的诱惑就越大，而Numbers 会更好，并且会遇到类型的限制。问题是，这些限制在很大程度上是故意的。你可以通过不使用BigInt 来避免这些限制，而不是回避它们并扔掉一些东西。
【讨论】：
Math 的事情”好吧，这是一个公平的观点。 “通常要快得多” 我并不是说你在那个方面错了，但我想看到一些基准或一些好的证据。我无法通过快速谷歌搜索找到好的来源。