BigInt的核心作用是用任意精度整数表示法杜绝大整数运算精度丢失；创建须用字符串或n后缀避免Number污染，运算需全程保持类型纯净，JSON交互需手动字符串转换，适用于超大ID、金融整数计算、密码学等场景。
JavaScript 中 BigInt 的核心作用，就是让大整数运算不再“猜答案”——它不靠浮点近似，而是用任意精度的整数表示法，从源头杜绝精度丢失。
怎么创建才不会一开始就失真
关键在于初始化必须避开 Number 类型的污染：
- 优先用字符串入参：BigInt("900719925474099199999999999999")，哪怕数字看着像整数，也别写成
BigInt(900719925474099199999999999999)，因为传入前 Number 已经四舍五入了 - 字面量写法最直观：
1234567890123456789012345678901234567890n，但只适用于硬编码常量，不适合动态数据 - 绝对不要传小数：
BigInt(10.5)或BigInt("10.5")都会报错，BigInt 只认整数
运算时怎么保证全程精确
所有参与计算的值必须是同一种类型，不能“混搭”：
- 加减乘除取模都支持：
100n + 200n、500n / 3n（结果是向下取整的166n） -
禁止和 Number 直接运算：
100n + 1报TypeError；要写成100n + 1n或100n + BigInt(1) - 比较可以跨类型判断大小（如
100n > 99返回true），但相等性严格区分类型：100n === 100是false
怎么安全地跟外部系统打交道
BigInt 不能直接进 JSON，也不能直接塞给 Math 方法或 Date 构造器：
立即学习“Java免费学习笔记（深入）”；
- 序列化时手动转字符串：
JSON.stringify({ id: myId.toString() })，接收端再用BigInt(data.id)恢复 - 不支持
Math.sqrt()、Math.pow()等，需要自己实现或借助第三方大数库 - 布尔上下文里，
0n是假值，其余都是真值，可用于条件判断
什么场景下该果断用 BigInt
不是所有大数都需要 BigInt，但以下情况建议默认启用：
- 数据库主键、Snowflake ID、区块链地址等超长整数 ID（常见长度远超
2^53） - 金融系统中以“分”为单位的金额计算（避免
0.1 + 0.2类误差） - 密码学运算、哈希处理、RSA 大素数操作
- 高精度计数器（比如服务请求总量突破千万亿次）
