做 SpringBoot 后端开发的同学，大概率会遇到一个诡异的参数接收问题：
同样是驼峰命名的字段，userId 前端传 userId 能正常接收，但 uId 前端传 uId 却接收不到，必须传uid 才能拿到值。
明明都是驼峰命名，为什么会有这种差异？今天就把这个高频坑彻底讲透，避免后续再踩雷。
一、问题复现（必看，你一定遇到过）
先上代码，直观感受问题：
后端实体类（用 Lombok 的 @Data 注解，自动生成 getter/setter）：
@Data
public class UserParam {
// 正常：前端传 userId，后端能接收
private Long userId;
// 异常：前端传 uId 接收不到，必须传 uid
private Long uId;
}
后端接口：
@RestController
@RequestMapping("/user")
public class UserController {
@PostMapping("/test")
public String test(@RequestBody UserParam param) {
System.out.println("userId: " + param.getUserId());
System.out.println("uId: " + param.getuId());
return "success";
}
}
前端请求体对比：
- 正常情况（userId）：
{"userId": 123}→ 后端能拿到 123 - 异常情况（uId）：
{"uId": 456}→ 后端拿到 null - 异常解决：
{"uid": 456}→ 后端能拿到 456
是不是很诡异？同样是驼峰，为什么 uId 这么特殊？
二、底层原因：Jackson 反序列化的“短驼峰陷阱”
核心答案：SpringBoot 默认使用 Jackson 作为 JSON 反序列化工具，而 Jackson 对“短驼峰”（单个字母 + 大写字母开头，如 uId、aName）的映射规则，和标准驼峰（如 userId）不一样。
1. 标准驼峰（userId）的映射规则
对于 userId 这种 标准小驼峰（第一个单词全小写，后续单词首字母大写），Jackson 会默认按“原样映射”：
后端字段 userId → 可匹配前端传入的 userId（完全一致），也能兼容 user_id（蛇形命名，Jackson 自动转换）。
这也是为什么我们平时写 userId、orderId 时，从来不用额外处理，前端传对应驼峰就能正常接收。
2. 短驼峰（uId）的映射规则（坑点所在）
对于 uId 这种 单个字母 + 大写字母 的短驼峰，Jackson 会触发一个“特殊缩写规则”：
Jackson 会认为 uId 是“全小写缩写”，自动将其映射为 uid，而不是我们预期的 uId。
也就是说：
- 后端字段
uId→ Jackson 会去匹配前端传入的uid（全小写） - 前端传入
uId（驼峰）时，Jackson 识别不到，就会给字段赋值为 null
同理，类似的 aId、bName、cAge 都会有这个问题，前端必须传 aid、bname、cage 才能正常接收。
3. 补充：getter/setter 方法的影响
有同学可能会问：Lombok 自动生成的 getter/setter 会不会有问题？
其实问题不在 getter/setter 本身，而是 Jackson 解析时，会根据字段名推导 getter/setter 方法名，再根据方法名反向映射 JSON 字段名。
对于 uId，Lombok 生成的 getter 是 getuId()，Jackson 解析这个方法名时，会认为对应的 JSON 字段是 uid；而 userId 生成的 getUserId()，会被解析为 userId，这就是差异的根源。
三、3 种解决方案（按推荐度排序）
知道了原因，解决起来就很简单了，推荐优先使用方案 1，稳定且无副作用。
方案 1：用 @JsonProperty 强制指定映射关系（最强最稳）
在 uId 字段上添加 Jackson 提供的 @JsonProperty 注解，明确指定 JSON 字段名就是 uId，强制 Jackson 按我们预期的规则映射。
代码修改如下：
@Data
public class UserParam {
private Long userId;
// 关键：强制指定 JSON 字段名为 uId
@JsonProperty("uId")
private Long uId;
}
修改后，前端传 {"uId": 456} 就能正常接收，完美解决问题。
这种方式的优势：不影响其他字段，精准解决当前问题，符合 Java 命名规范，也是企业开发中最常用的方式。
方案 2：统一字段命名，避免短驼峰（最省心）
既然短驼峰容易踩坑，最简单的方式就是避免使用 uId 这种命名，直接改用标准驼峰 userId、userIdCard 等。
比如将 uId 改为 userId（如果业务允许），或者 userUid，这样既能避免 Jackson 的映射陷阱，也能让字段名更规范、更易读。
毕竟，代码的可读性和可维护性，远比“少写几个字母”重要得多，这也是主流 Java 命名规范（如阿里巴巴规范、Google 规范）所倡导的“描述性优先”原则。
方案 3：配置 Jackson 全局策略（不推荐，慎用）
如果项目中有大量短驼峰字段，不想逐个加@JsonProperty，可以配置 Jackson 全局命名策略，强制其按标准驼峰映射。
添加配置类：
@Configuration
public class JacksonConfig {
@Bean
public ObjectMapper objectMapper() {
ObjectMapper mapper = new ObjectMapper();
// 配置为标准小驼峰映射
mapper.setPropertyNamingStrategy(PropertyNamingStrategies.LOWER_CAMEL_CASE);
return mapper;
}
}
⚠️ 注意：Jackson 2.12 版本后，PropertyNamingStrategy.LOWER_CAMEL_CASE 已被废弃，建议使用 PropertyNamingStrategies.LOWER_CAMEL_CASE（注意多了个 s）。
这种方式的缺点：全局配置会影响所有字段的映射规则，可能会和其他字段的预期映射冲突，增加排查成本，非必要不推荐使用。
四、避坑总结（重点记这3点）
- 标准驼峰（如 userId、orderId）：前端传对应驼峰即可正常接收，无需额外处理；
- 短驼峰（如 uId、aName）：Jackson 会自动映射为全小写（uid、aname），前端传驼峰无法接收；
- 最优解决方案：给短驼峰字段加
@JsonProperty("字段名")，强制指定映射关系，或直接避免使用短驼峰。
五、扩展思考
为什么 Jackson 会有这样的映射规则？
其实是为了兼容一些不规范的 JSON 命名习惯，比如有些前端开发者会将所有字段设为全小写（uid、username），而后端用短驼峰命名时，Jackson 自动兼容全小写，减少前后端对接成本。
但这种“兼容”反而给我们带来了坑，尤其是在严格遵循驼峰命名规范的项目中，很容易出现参数接收失败的问题。
另外补充一点：如果前端传的是蛇形命名（如 user_id、u_id），后端用标准驼峰（userId、uId），Jackson 会自动转换，无需额外处理（前提是没有配置全局命名策略）。
最后，建议大家在项目中统一字段命名规范，优先使用标准驼峰，避免短驼峰，既能减少踩坑，也能提升代码的一致性和可维护性。如果确实需要使用短驼峰，记得加上 @JsonProperty 注解哦～
感谢 掘友@一叶一天堂 哈 3526889031863533
