bigint与number不能直接混合运算，必须显式转换：需精度时用bigint()转字符串或整数，避免小数；转number仅限安全整数范围且承担精度风险；比较时应统一类型，协作中建议后端传字符串、前端转bigint并自定义json序列化。
BigInt 和 Number 不能直接混合运算，必须显式转换。关键不是“能不能转”，而是“怎么转才不丢精度、不出错”。
什么时候该转 BigInt？
当你需要保持大整数精度时，应把 Number 转为 BigInt：
- 使用 BigInt() 构造函数，传入整数或数字字符串（不能是小数、NaN、空字符串）
- 示例：
BigInt(123)、BigInt("9007199254740992")✅ - 错误写法：
BigInt(12.5)、BigInt("12.5")、BigInt("")❌（会抛出 SyntaxError 或 RangeError） - 注意：如果 Number 已超出
Number.MAX_SAFE_INTEGER（即 9007199254740991），先转成字符串再传给BigInt()，否则原始值在 Number 阶段就已失真
什么时候该转 Number？
仅当确认数值在安全范围内，且后续要参与 Math 方法、JSON 序列化或浮点运算时才转：
- 用 Number() 转换 BigInt，但必须承担精度风险
- 示例：
Number(9007199254740992n)→9007199254740992✅（刚好在边界内） - 危险示例：
Number(9007199254740992n + 1n)→9007199254740992❌（+1 后被截断，精度丢失） -
Number(100n)安全；Number(1e20n)不安全 —— 判断依据是结果是否 ≤Number.MAX_SAFE_INTEGER
比较和条件判断中的转换陷阱
比较时类型差异容易引发意外行为：
-
10n === 10→false（类型不同，严格相等不成立） -
10n == 10→true（== 会隐式转 Number，但不推荐依赖） - 建议统一转为同类型再比：
10n === BigInt(10)或Number(10n) === 10（后者需确保无精度损失） - 在
if、三元运算中，0n是 falsy，其余 BigInt 均为 truthy，无需转 Number
实际协作场景的转换建议
前后端交互或 API 处理中，避免运行时转换：
- 后端返回大整数时，一律用字符串字段（如
"id": "123456789012345678901234567890"） -
前端收到后，立即用
BigInt(str)转为 BigInt 存储或计算 - 需要 JSON 序列化时，不要直接
JSON.stringify(bigint)（会报错），改用自定义 replacer：JSON.stringify(obj, (k, v) => typeof v === 'bigint' ? v.toString() : v) - 封装工具函数统一处理，比如
toSafeBigInt(val)内部校验输入是否有效，避免散落多处的BigInt()调用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
