用 BigInt 与后端金融 API 交互需坚持“进得准、算得对、出得稳”三原则：金额统一以“分”为单位用字符串传，前端转 BigInt 计算，展示时自行格式化为“元”，收发 JSON 时精准转换、避免全局处理，且必须后端协同返回字符串。
用 BigInt 与后端金融 API 交互，核心不是“能不能转”，而是确保“进得准、算得对、出得稳”——三步断链，缺一不可。
金额字段统一用“分”作单位，全程 BigInt 持有
金融金额绝不能以“元”为单位走 Number 类型，否则小数点运算（如 0.1 + 0.2）必然失真。必须约定后端返回金额字段（如 amount_cents）为字符串，前端立即转 BigInt：
-
正确示例：
const amount = BigInt(response.amount_cents); // "12345678901234567890" → 12345678901234567890n - 所有加减乘除、比较、取模都用
n后缀或 BigInt 字面量：amount + 100n、amount > 100000000n、amount % 100n - 禁止混用 Number：
amount + 100会报错；amount === 100000000返回 false（隐式转换已失效）
API 请求/响应中规避 JSON 原生限制
标准 JSON.stringify() 不支持 BigInt，JSON.parse() 默认把数字当 Number 解析——这两处是精度丢失高发区：
响应式金融公司HTML5网站模板
下载
响应式金融公司HTML5网站模板是一款适合提供家族财富管理、节税互助基金、保险投资、节税投资、财务策划和在线投资计划等服务的金融公司宣传网站模板下载。提示：本模板调用到谷歌字体库，可能会出现页面打开比较缓慢。
-
接收时：不用全局 reviver，而是按字段精准拦截。例如只对已知的金融字段（
amount_cents、balance_cents、order_id）做转换：JSON.parse(jsonStr, (k, v) => ['amount_cents', 'balance_cents'].includes(k) && typeof v === 'string' ? BigInt(v) : v) -
发送时：提交前手动将 BigInt 转字符串：
{ amount_cents: userAmount.toString() }。后端应明确按字符串解析为 int64 或 big integer 类型 - 不推荐无差别使用
json-bigint，易误转手机号、状态码等本该是小整数的字段
展示与业务逻辑分离：字符串用于渲染，BigInt 用于计算
BigInt 不能直接渲染，也不该作为 React key 或 URL 参数；但也不能为图方便提前转 Number——必须守住安全边界：
-
展示“元”单位：自己控制两位小数格式：
const yuan = (amount / 100n).toString();const fen = (amount % 100n).toString().padStart(2, '0');
拼成${yuan}.${fen} -
作为 key 或 URL 参数：始终用
amount.toString()，而非String(amount)（虽等效，但语义更清晰） - 仅当确认值 ≤ Number.MAX_SAFE_INTEGER（9007199254740991）时，才可转 Number：比如日交易笔数统计，但账户余额、累计流水等一律禁用
与后端协同的关键约定
前端单方面努力无法根治问题，必须推动后端配合：
- 所有可能超 16 位的字段（订单 ID、用户 ID、金额分、纳秒时间戳）统一返回字符串，不传 JSON 数字
- 后端序列化时主动调用
String(id)或配置注解（如 Spring Boot 的@JsonFormat(shape = JsonFormat.Shape.STRING)） - 接口文档中明确标注字段类型语义，例如：
"amount_cents": "string (integer in cents)"，而非模糊写"number"
