Spring Boot中getById与getOne方法的区别及正确使用方式
本文详解mybatis-plus中getbyid()与getone(lambdaquerywrapper)在单条记录查询中的核心差异：前者基于主键精确查询、查不到抛异常；后者按条件查询、查不到返回null，二者语义与行为均不等价。
在Spring Boot + MyBatis-Plus开发中，初学者常误认为getById(id)和getOne(new LambdaQueryWrapper().eq(Entity::getId, id))功能完全等价——实际上二者在设计意图、执行逻辑与异常处理上存在本质区别，直接混用可能导致空指针异常或业务逻辑隐性失败。
✅ getById(id)：主键安全查询（推荐用于ID已知场景）
该方法专为主键查询设计，底层调用selectById，会生成形如 SELECT * FROM category WHERE id = ? 的SQL。其特点是：
- 强契约性：预期ID必存在；若数据库无匹配记录，默认抛出IllegalArgumentException或自定义异常（取决于全局配置）；
- 性能最优：利用主键索引，无需解析复杂条件；
- 语义明确：“我要这个ID的实体，它必须存在”。
// ✅ 推荐：ID已知时首选，配合try-catch或全局异常处理器
try {
Category category = categoryService.getById(categoryId);
String categoryName = category.getCategoryName(); // 安全调用
} catch (IllegalArgumentException e) {
throw new BusinessException("分类不存在，ID：" + categoryId);
}⚠️ getOne(wrapper)：条件查询的“首个匹配项”（非主键专用）
该方法本质是 SELECT * FROM category WHERE ... LIMIT 1，适用于任意字段组合查询。关键特性包括：
- 宽松语义：仅返回第一个满足条件的记录（无排序时结果不确定），未匹配则静默返回null；
- 无主键优化：即使条件含主键，仍走通用条件解析流程，可能绕过索引优化；
- 易埋隐患：若忽略null检查，后续调用category.getCategoryName()将触发NullPointerException。
// ❌ 危险写法：未判空导致NPE LambdaQueryWrapperwrapper = new LambdaQueryWrapper<>(); wrapper.eq(Category::getId, categoryId); Category category = categoryService.getOne(wrapper); String name = category.getCategoryName(); // category可能为null！ // ✅ 正确用法：必须显式判空 Category category = categoryService.getOne(wrapper); if (category == null) { throw new BusinessException("分类未找到，ID ：" + categoryId); } String categoryName = category.getCategoryName();
? 根本差异对比表
| 维度 | getById(id) | getOne(wrapper) |
|---|---|---|
| 设计目的 | 主键精确查询 | 通用条件查询（取第一条） |
| 空值处理 | 查不到抛异常（可配置） | 查不到返回null |
| SQL生成 | SELECT * FROM table WHERE id=? | SELECT * FROM table WHERE ... LIMIT 1 |
| 性能 | 最优（主键索引直达） | 依赖WHERE条件是否命中索引 |
| 适用场景 | ID确定且业务要求强一致性 | 多条件筛选、分页前取样、存在性校验 |
? 最佳实践建议
- 优先使用getById()：当明确通过主键查询且业务逻辑依赖实体存在性时（如REST API根据ID获取资源）；
- 慎用getOne()查主键：除非需统一抽象条件查询逻辑，否则属于“杀鸡用牛刀”，增加不确定性；
- 永远防御性编程：若选用getOne()，务必对返回值判空；若选用getById()，需配置全局异常处理器统一处理NoSuchElementException等；
- 替代方案：MyBatis-Plus 3.4.0+ 提供getByIdOrDefault(id, defaultEntity)（需自定义），或使用lambdaQuery().eq(...).one()（更语义化）。
归根结底，二者不是“等价替换”，而是不同语义场景下的工具选择——理解差异，方能写出健壮、可维护的查询代码。
