在 JavaScript 开发中，将 BigInt 转换为 Number 是常见需求，很多开发者第一反应是直接调用 Number() 完成转换。但这里有隐藏陷阱——Number 类型的精度上限为 2⁵³−1（即 9007199254740991），而 BigInt 理论上可以表示任意大的整数。一旦 BigInt 的值超出安全整数范围，强制转换将导致精度丢失，甚至静默返回错误结果。
先介绍最直接的方案，也是大多数开发者首先想到的：Number() 强制转换。这种方法仅适用于“较小”的 BigInt——即数值位于 -(2⁵³−1) 到 2⁵³−1 区间内的情况。例如 Number(123n) 返回 123，Number(-456n) 返回 -456，边界值 Number(9007199254740991n) 也能正确得到 9007199254740991。然而一旦超出安全范围，比如 Number(9007199254740993n)，结果却是 9007199254740992——精度已悄然丢失一位。
部分开发者尝试使用 parseInt() 或 parseFloat() 来绕过问题。实际上这些函数内部也会先将 BigInt 转为字符串再解析，精度问题与 Number() 完全一致。例如 parseInt(9007199254740993n) 依旧返回 9007199254740992，并不可靠。至于 parseFloat 更不适用，BigInt 本身不含小数点，用 parseFloat 处理 BigInt 属于张冠李戴。
那么问题来了：当业务场景要求绝对不丢失精度时，该如何处理？答案是先进行安全检查。在调用 Number() 之前，判断 BigInt 是否在 Number.MIN_SAFE_INTEGER 与 Number.MAX_SAFE_INTEGER 之间。满足条件再转换，否则抛出异常或执行降级逻辑。以下是示例代码：
function safeBigIntToNumber(bigInt) {
if (bigInt >= -9007199254740991n && bigInt <= 9007199254740991n) {
return Number(bigInt);
}
throw new RangeError('BigInt exceeds Number precision');
}
最后指出一个常见误区：如果原始数据本身包含小数（例如来自 JSON 或用户输入），那么它本来就不适合用 BigInt 存储。BigInt 是纯粹的整数类型，没有小数部分。若非要模拟“带小数的 BigInt”，需要自行约定缩放倍数（比如使用微秒、分、毫秒作为单位），转换时再除以该倍数。但这属于业务层的设计决策，与语言原生的转换机制已是两码事。
