秒杀系统中订单号生成绝不能依赖JavaScript原生Number类型，因其在超过Number.MAX_SAFE_INTEGER（9007199254740991）后精度丢失，导致重复或错乱；应改用字符串、BigInt、雪花ID、UUID压缩或数据库序列等可靠方案，并设置预警与校验机制。
秒杀系统中，若用 JavaScript 原生数字类型（Number）直接生成或累加订单号，当订单量接近 Number.MAX_SAFE_INTEGER（即 9007199254740991）时，整数精度将丢失，导致订单号重复、错乱甚至覆盖——这不是理论风险，而是真实发生的线上故障。
理解 Number.MAX_SAFE_INTEGER 的实际边界
Number.MAX_SAFE_INTEGER 表示 JavaScript 能**安全表示且不丢失精度的最大整数**。超过它后，相邻两个可表示的整数间隔大于 1（例如 9007199254740992 === 9007199254740993 会返回 true），订单号一旦落入该范围，自增逻辑就会“跳号”或“撞号”。
- 它约等于 9 × 10¹⁵，看似很大，但若每秒生成 1 万单，撑不过 3 年就逼近临界值；
- 更现实的是：多机集群下各节点独立计数 + 时间戳拼接 + 序列号组合，若序列号部分用 JS 数字运算，仍可能在局部溢出；
- Node.js 后端若混用
parseInt()、+运算或 JSON 解析大数字 ID，也可能隐式触发精度丢失。
在订单号生成环节主动设防
预警不等于等它爆，而是在设计阶段就隔离风险。关键原则是：**原始订单号的生成与递增，绝不依赖 JS 的原生 Number 类型做主键计数器**。
- 用字符串代替数字存储和传递订单号（如
"ORD_202405201023456789"），避免解析/计算过程中的隐式转换； - 若需自增序列号（如当日第 N 单），改用
BigInt维护（let seq = 1n），并在溢出前 10⁶ 预警（if (seq > BigInt(Number.MAX_SAFE_INTEGER) - 1000000n)）； - 在服务启动或每日零点，检查当前最大序列值是否已超
0.9 * Number.MAX_SAFE_INTEGER，超则触发告警并自动切换新号段（如换日期前缀或加节点标识）。
监控与兜底：运行时动态检测溢出征兆
即使设计合理，也要防止上游异常输入或日志误解析引入大数字。可在订单创建核心路径加入轻量校验：
- 对所有传入的 numeric-type 订单 ID（如来自 query、body 或 Redis 计数器），先用
Number.isSafeInteger(id)判断； - 若为字符串 ID，尝试用
BigInt(id)解析，捕获SyntaxError（非法格式）或RangeError（超出BigInt安全上限，间接提示原始数值已失真）； - 在 Kafka 消费、DB 写入、ES 索引等关键节点，记录
id.toString().length分布，当出现大量 ≥17 位数字 ID 时，触发“高风险 ID”审计任务。
真正可靠的替代方案
不要把秒杀系统的命脉押在 JS 数字精度上。生产环境应采用更健壮的编号机制：
-
雪花 ID（Snowflake）：64 位整数，时间+机器+序列组成，后端用
BigInt或字符串处理，前端只展示不计算； -
UUID v4 + 编码压缩：生成
uuidv4()后用 Base32 或 Crockford Base32 缩短（如"xk2m9p4z"），完全规避数字溢出； -
数据库序列 + 业务前缀：MySQL
AUTO_INCREMENT或 PostgreSQLSEQUENCE保证唯一递增，应用层拼接"SECK_20240520_" + dbSeq，dbSeq 始终远小于MAX_SAFE_INTEGER。
把 Number.MAX_SAFE_INTEGER 当作一道红色警戒线，不是用来突破的，而是用来提前绕行的。预警的本质，是让系统在数字失真发生前，就切换到不依赖 JS 数值精度的轨道上。
