当前位置：首页 > news >正文

java数据类型：Long 和 long 在雪花算法ID下的陷阱

news 2026/7/14 5:11:39

Long和long在雪花算法ID（19位长整型）下的坑，或者前端JS解析后端Long精度丢失的问题，是中国互联网公司线上事故的高发区，尤其是涉及分布式ID和前后端对接时。我挨个给你拆解，附带真实故障场景。

第一坑：Long 和 long 在雪花算法ID下的陷阱

1. 背景知识：雪花算法ID有多长？

雪花算法（Snowflake）生成的ID是一个64位（bit）的Long型数字，通常由：

1位符号位（固定0）
41位时间戳（可用69年）
10位机器ID
12位序列号（同一毫秒内可生成4096个ID）

最终结果：一个类似1478733705032859648的数字，长度是19位。

2. 陷阱一：用`long`接收没问题，但计算会溢出？

结论：用long接收19位ID完全没问题（Long.MAX_VALUE ≈ 9.22e18，19位数字最大约9.9e18，在范围内）。

真正的坑在于：如果你不小心用了Long包装类，在做算术运算时自动拆箱，如果对象是null，就会抛NullPointerException。所以ID字段强烈建议用long（基本类型），因为它永不可能是null（数据库主键必有值）。

3. 陷阱二：数据库类型选错（致命！）

数据库类型	最大值	能否存19位雪花ID？
MySQL INT	21亿（约2.1e9）	❌ 存不下，截断或报错
MySQL BIGINT	9.22e18	✅ 完美支持
Oracle NUMBER(19)	19位	✅ 完美支持

真实事故：某小公司用INT存雪花ID，当ID超过21亿时，数据插入直接报错Out of range，线上订单无法创建，紧急改表结构才恢复。

解决方案：建表时务必用BIGINT：

sql

CREATE TABLE orders ( id BIGINT PRIMARY KEY, -- 不是 INT！ order_no VARCHAR(64) );

第二坑：前端JS解析后端Long精度丢失（高频线上事故）

这是最经典的坑，90%的互联网公司都踩过。

1. 问题根源：JS的数字精度限制

Java 的Long最大值：9223372036854775807（19位）
JavaScript 的Number类型是双精度浮点数，安全整数范围只有：
- -(2^53 - 1)到(2^53 - 1)
- 即：-9007199254740991到9007199254740991（16位）

结论：当后端返回的19位雪花ID超过9007199254740991时，JS解析会丢失精度。

2. 真实事故演示

后端（Java）返回JSON：

json

{ "id": 1478733705032859648, "userName": "张三" }

前端（JS）接收后：

javascript

const data = JSON.parse('{"id": 1478733705032859648, "userName": "张三"}'); console.log(data.id); // 输出：1478733705032859600 （最后两位变成了00，精度丢失了！）

后果：

前端用这个ID去查询详情 → 查不到数据
前端用这个ID去更新 → 更新了错误的数据
前端用这个ID做删除 → 删错了记录

3. 解决方案（3种主流做法）

方案一：后端转为字符串返回（最常用、最稳妥）

思路：后端在序列化时，将Long类型的ID自动转为String。

Spring Boot + Jackson 全局配置：

java

@Configuration public class JacksonConfig { @Bean public ObjectMapper objectMapper() { ObjectMapper mapper = new ObjectMapper(); SimpleModule module = new SimpleModule(); // 将所有Long类型序列化为String module.addSerializer(Long.class, ToStringSerializer.instance); module.addSerializer(Long.TYPE, ToStringSerializer.instance); mapper.registerModule(module); return mapper; } }

返回结果：

json

{ "id": "1478733705032859648", // 变成了字符串！ "userName": "张三" }

前端拿到字符串，直接使用，不会丢失精度。

方案二：前端使用 BigInt（ES2020新特性）

JS原生支持BigInt类型，可以精确表示任意大整数。

javascript

// 后端返回字符串，前端转BigInt const id = BigInt("1478733705032859648"); console.log(id); // 1478733705032859648n

缺点：浏览器兼容性要求较高（Chrome 67+），且JSON.parse默认不会自动转BigInt。

方案三：使用注解局部控制（精细化）

如果不想全局改，可以用注解单独指定某个字段：

java

@JsonSerialize(using = ToStringSerializer.class) private Long id; // 只有这个字段转字符串

4. 数据库查询时的坑（补充）

如果你用Long id作为查询条件，前端传过来的是字符串"1478733705032859648"，Spring MVC 能自动转成Long，但前提是：前端传的字符串不能超过Long.MAX_VALUE，否则会报NumberFormatException。

解决办法：将Controller入参也改为String，然后手动转：

java

@GetMapping("/order/{id}") public Result getOrder(@PathVariable String id) { // 如果需要，转成Long（但推荐直接用String查数据库，BIGINT支持字符串比较） return service.getOrder(id); }

终极总结（一张表解决所有疑问）

场景	推荐方案	原因
实体类ID字段	`long`（基本类型）	绝对不可能为null，避免拆箱NPE
数据库ID字段	`BIGINT`	支持19位雪花ID
后端返回给前端	转为`String`	避免JS精度丢失
前端使用ID	当作字符串处理	不要转成Number，直接传给后端
Controller入参	`String`接收	避免超长导致转换异常

生产环境最佳实践（直接抄作业）

Entity类：

java

public class Order { private long id; // 基本类型，永不null private Long userId; // 外键可能为null，用包装类 }

Controller：

java

@GetMapping("/order/{id}") public Result getOrder(@PathVariable String id) { // 用String接收 // 调用Service时，如果需要可以转为long return orderService.getById(Long.parseLong(id)); }

Jackson配置（全局转String）：

java

@Configuration public class WebConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer customizer() { return builder -> { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(long.class, ToStringSerializer.instance); }; } }

数据库DDL：

sql

CREATE TABLE `order` ( `id` BIGINT PRIMARY KEY COMMENT '雪花ID', -- 不是INT！ `user_id` BIGINT COMMENT '用户ID', ... ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

最后送你一句保命箴言：