bigint 与 number 不能混用，需显式转换类型；json 不支持 bigint，序列化前须转字符串并手动恢复；比较应统一用 === 或大小运算符，避免 ==；除法向零截断，幂运算注意性能与安全。
BigInt 不能直接和 Number 混用，否则会报 TypeError: Cannot mix BigInt and other types
这是最常踩的坑：哪怕只是写 123n + 456（一个 BigInt 加一个普通数字），JS 就会立刻抛错。它不自动转换，也不容忍隐式类型混合。
必须显式统一类型：
- 所有参与运算的数字都得是
BigInt，用BigInt()构造函数或字面量后缀n转换 -
BigInt()只接受整数字符串或安全整数范围内的Number；传入小数会直接报RangeError - 从后端 API 接收的长数字字符串（如
"9007199254740991999"）必须先转成字符串再进BigInt()，不能先用parseInt或Number解析——那一步就已精度丢失
JSON 不支持 BigInt，序列化时会报 TypeError: Do not know how to serialize a BigInt
前端发请求或存 localStorage 时，如果对象里有 BigInt 字段，JSON.stringify() 直接崩。这不是 bug，是标准限制。
- 临时方案：序列化前遍历对象，把
typeof x === 'bigint'的字段转成字符串：x.toString() - 反序列化时，再手动用
BigInt(str)恢复（注意校验是否为有效整数字符串） - 别用
JSON.stringify(obj, (k, v) => typeof v === 'bigint' ? v.toString() : v)一劳永逸——它无法区分“本意就是字符串的 ID”和“需要还原的 BigInt”，容易埋雷
比较操作符 === 和 == 对 BigInt 行为不同
=== 严格类型+值相等，123n === 123 是 false；但 == 在 BigInt 和 Number 间会尝试抽象相等转换，123n == 123 居然是 true。
- 别依赖
==做判断，它在跨类型时行为反直觉，且 V8 等引擎对大数的抽象相等实现可能有细微差异 - 统一用
===，并确保比较双方都是BigInt；若需和 Number 比较，先转成同类型再比 - 大小比较（
, <code>>）可以跨类型，123n > 122合法且安全，但仅限于数值大小，不用于相等性判断
大数幂运算、除法、取模容易忽略精度陷阱
BigInt 支持 **、/、%，但除法是**向零截断**，不是四舍五入，且不返回小数部分。
-
10n / 3n得3n，余数被丢弃；要取余必须显式用%，或组合divmod逻辑 -
12345678901234567890n ** 2n没问题，但结果位数爆炸，内存和计算时间随输入长度非线性增长，别在循环里无节制调用 - 涉及加密或哈希场景（如 RSA 模幂），优先用成熟库（如
jsrsasign），别手写BigInt运算——边界条件、常数时间防护、侧信道防御这些，自己很难做全
BigInt 的核心约束很清晰：它是个独立类型，不是 Number 的升级版。所有“想当然”的混用、自动转换、JSON 直出，都会在某个环节卡住。真正安全的前提，是承认它和 Number 是两个世界，中间的桥必须你亲手搭，而且每块砖都要检查。
