bigint 通过任意精度二进制补码避免整数精度丢失，但需严格避免与 number 混用、用字符串初始化、序列化时手动处理，并优先以字符串处理标识符。
BigInt 本身不“避免”精度问题，而是从设计上就不产生整数精度丢失——它用任意精度二进制补码表示整数，只要内存够，就能精确存下任何大小的整数。真正要做的，是正确使用它，绕过 Number 类型的污染和隐式转换陷阱。
只在必要时创建，且必须用字符串初始化
一旦数字被 JS 当作 Number 解析过，精度就已不可逆丢失。所以不能写 BigInt(9007199254740993)，因为这个字面量在传入前已被转成近似值（9007199254740992）。安全做法只有两种：
- 用字符串字面量加
n后缀：9007199254740993n - 用字符串调用
BigInt("9007199254740993")
后端返回的订单号、雪花 ID 等，应在响应解析阶段就固化为字符串（如用 json-bigint 配置 storeAsString: true），再按需转 BigInt，而不是等数据进入对象后再补救。
全程保持类型纯净，禁止与 Number 混用
BigInt 和 Number 是完全不同的类型，混合运算会直接抛 TypeError，这不是缺陷，而是防止静默错误的安全机制：
- ✅ 正确：
100n + 200n、id > threshold（两边都是 BigInt） - ❌ 错误：
100n + 200、id === 1234567890123456789
比较、算术、位运算都要求操作数类型一致。若需跨类型判断（比如和常量比），先把常量也转成 BigInt：id > BigInt("1000000")。
序列化与通信必须手动适配
JSON 原生不支持 BigInt，JSON.stringify({ id: 123n }) 会直接报错。实际传输前需主动处理：
- 转字符串：
{ id: id.toString() }—— 适用于前端展示、URL 参数、localStorage 存储 - 转回 BigInt：
BigInt(data.id)—— 仅在接收方明确需要数值语义时才做 - 发给后端时注意格式：若接口要求 JSON 数字，字符串字段可能被拒收；此时应和服务端约定统一用字符串传 ID，而非强行塞 BigInt
别把标识符当数字用
订单号、用户 ID、消息 ID 等本质是标识符，不是可计算量。除非业务真有数值需求（如分页偏移、ID 范围校验），否则全程用字符串即可，根本不需要 BigInt：
- 展示、跳转、传参、缓存，全部用原始字符串
- 避免
parseInt、Number()、+运算符触发隐式转换 - 不要为了“看起来更规范”而无意义地转 BigInt，反而增加出错风险和 GC 开销
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
