在 JavaScript 中，数字（Number）类型使用 IEEE 754 双精度浮点数格式表示，这使得它在表示整数时存在一个安全范围限制：Number.MAX_SAFE_INTEGER，即：
Number.MAX_SAFE_INTEGER === 9007199254740991
超过这个值的整数在 JavaScript 中就可能产生精度丢失，这在处理大整数（如密码学、金融 ID、高精度计数等）时带来了严重问题。
✅ 一、为什么 Number 类型不能表示更大的整数？
JavaScript 的 Number 类型使用 64 位双精度浮点数格式存储，其中：
| 部分 | 位数 | 说明 |
|---|---|---|
| 符号位 | 1 位 | 表示正负 |
| 指数部分 | 11 位 | 表示数值范围 |
| 尾数（有效数字）部分 | 52 位 | 表示精度 |
由于尾数部分只有 52 位，所以 JavaScript 只能精确表示从 -2^53 + 1 到 2^53 - 1 之间的整数：
Number.MIN_SAFE_INTEGER === -9007199254740991
Number.MAX_SAFE_INTEGER === 9007199254740991
一旦超过这个范围，整数就可能无法精确表示，从而导致精度丢失。
✅ 二、精度丢失的后果
示例 1：超过安全整数的计算错误
9007199254740992 === 9007199254740993 // true ❌
这显然不符合数学逻辑。
示例 2：处理大 ID 时出错
在分布式系统中，经常使用 64 位整数（如 Twitter 的 Snowflake ID）表示唯一标识符：
const id = 9223372036854775807; // 一个 64 位整数
console.log(id); // 在 JS 中可能被错误表示
JavaScript 的 Number 类型无法安全地处理这类大整数，容易导致数据错误或冲突。
✅ 三、此前的解决方案：依赖第三方库
在 BigInt 出现之前，开发者通常使用第三方库来处理大整数：
BigInt.jsbignumber.jsbig-integerdecimal.js
这些库虽然可以解决问题，但也带来了以下问题：
- 增加代码复杂度；
- 性能开销大；
- 与原生类型不兼容；
- 语法不直观；
✅ 四、ECMAScript 引入 BigInt 的提案
为了解决上述问题，ECMAScript 提出了 BigInt 类型，并在 ES2020（ES11） 中正式纳入标准。
✅ BigInt 的特点：
- 表示任意精度的整数；
- 支持正负；
- 可以表示超过
Number.MAX_SAFE_INTEGER的整数； - 语法：在数字末尾加
n；
示例：
const big = 9007199254740995n;
console.log(big); // 9007199254740995n ✅
typeof 123n === 'bigint'; // true
✅ 五、BigInt 的优势
| 优势 | 描述 |
|---|---|
| 精确性 | 可以表示任意大的整数，不会丢失精度 |
| 性能 | 原生支持，比第三方库更高效 |
| 语法简洁 | 使用 n 后缀即可创建 |
| 安全性 | 适用于密码学、ID 生成、金融计算等场景 |
| 兼容性好 | 现代浏览器和 Node.js 均已支持 |
✅ 六、注意事项
BigInt不能与Number混合使用，会抛出错误：
100n + 100; // TypeError
- 不能用于
Math对象的方法中； - 不支持小数；
- JSON 序列化不支持
BigInt（需自定义处理）；
✅ 七、一句话总结
JavaScript 的
Number类型只能安全表示±9007199254740991范围内的整数。为了解决大整数运算中的精度丢失问题，ECMAScript 提出了BigInt类型，它支持任意精度的整数运算，是现代 JavaScript 处理大整数的标准方案。
💡 进阶建议
- 使用
BigInt处理唯一 ID、密码学、金融等需要大整数精度的场景； - 避免
BigInt与Number混合使用； - 使用 TypeScript 时注意
bigint类型的声明； - 使用
JSON.stringify()时需自定义转换函数； - 使用 ESLint 规则防止误用大整数；
