在Spring Boot应用架构中，服务层处于控制器与数据访问层之间，承担着业务规则编排与数据转换的职责。当底层仓库查询没有返回任何数据时，开发者往往面临一个具体抉择：是让方法返回一个空的集合对象，还是抛出一个异常来中断调用链。这个看似微小的设计差异，实际上会渗透到接口定义、前端处理逻辑以及整体系统的容错模型中，需要在动手写代码之前就明确约定。
空列表返回模式的适用场景与实现细节
对于诸如“查询某用户的所有订单”“获取部门成员列表”这类本质为集合查询的接口，返回空列表（如Collections.emptyList()或new ArrayList<>()）通常是更温和的处理方式。从语义上看，空集合依然是一个合法的集合，只是元素数量为0，调用方无需编写额外的异常捕获分支即可直接进行遍历或判空展示。这种方式降低了服务消费者与提供者之间的耦合，也符合RESTful设计中“资源存在但内容为空”的表达习惯。
在代码层面，我们可以借助Spring Data JPA的派生查询方法天然获得空列表。例如当findAllByUserId未命中时，框架本身就会返回空列表而非null，此时服务层只需直接透传即可。如果使用了MyBatis等需要手动映射的框架，则务必在XML或注解SQL的结果处理中做好空值防护，避免将null直接抛给上层。下面的示例展示了在Service中安全地返回空列表：
@Service
public class OrderService {
@Autowired
private OrderRepository orderRepository;
public List<Order> getOrdersByUser(Long userId) {
List<Order> result = orderRepository.findAllByUserId(userId);
// 防御性编程，确保永远不返回null
if (result == null) {
return Collections.emptyList();
}
return result;
}
}
采用空列表策略的优点显而易见：调用链不会被异常打断，前端拿到数组后可直接渲染“暂无数据”状态，监控告警也不会因为正常的空业务数据而误报。但其短板在于，如果调用方混淆了“业务上无数据”和“参数错误导致未查询”的界限，可能掩盖真正的配置或权限问题。因此在团队内部应当通过接口文档明确约定：集合查询一律返回空集合，不抛空结果异常。
抛出异常策略的业务语义与全局处理
当服务方法语义为“根据主键获取唯一实体”时，例如getUserById、loadConfigByName，如果未找到记录，返回null容易引发NullPointerException，而返回空列表则明显违背方法签名（返回类型不是集合）。此时抛出明确的业务异常，如UserNotFoundException，能够精准传达“期望的资源不存在”这一领域事件，使控制器层可以通过全局异常处理器转换为标准的HTTP 404或业务错误码。
Spring本身提供了Optional作为折中方案，但在服务层内部，我们更推荐主动判定并抛出自定义异常，因为这样可以在异常消息中附加追踪参数，便于日志排查。以下代码演示了一个典型的单实体检索及异常抛出逻辑：
@Service
public class UserService {
@Autowired
private UserRepository userRepository;
public User getUserById(Long id) {
return userRepository.findById(id)
.orElseThrow(() -> new ResourceNotFoundException("用户不存在，id=" + id));
}
}
// 自定义异常，继承RuntimeException以适配Spring事务回滚
public class ResourceNotFoundException extends RuntimeException {
public ResourceNotFoundException(String message) {
super(message);
}
}
为了让异常不污染每个Controller，我们通常配合@ControllerAdvice编写统一处理器，将各类业务异常映射为前端可消费的错误结构。这种方式的优势是业务语义清晰、错误边界明确，尤其适合写操作或强一致性要求的场景；缺点是如果滥用，将“列表为空”也视作异常，则会造成调用方大量try-catch，系统噪音增多。因此异常策略应限定在“单资源未命中”或“业务规则被打破”的情境下。
混合策略与团队规范落地建议
实际项目中更可取的做法是依据方法语义实施混合策略：集合型查询返回空集合，单实体查询抛异常，并通过代码评审与ArchUnit等架构测试工具固化规范。这样既能让列表接口保持健壮，又能让关键资源缺失被显式暴露。同时，在服务层向控制器返回之前，可以利用MapStruct等映射工具将空集合转换为对应的DTO空集合，避免泄漏内部实体结构。
为了直观对比两种策略，我们整理如下差异表供团队参考：
| 维度 | 返回空列表 | 抛出异常 |
|---|---|---|
| 适用方法 | 集合查询（List/Set返回） | 单实体查询（Entity/DTO返回） |
| 调用方处理 | 直接遍历或判空 | 需捕获或依赖全局处理 |
| HTTP映射 | 200含空数组 | 通常404或业务错误码 |
| 事务影响 | 无回滚 | 未捕获则当前事务回滚 |
最后，建议在项目根包下建立exception与constant包，集中维护异常类型与错误码，并在README或Wiki中写明服务层空结果处理约定。新成员入职后即可依据示例直接落码，减少因个人习惯不同导致的接口行为分裂。当这一策略与Spring Boot的校验框架、OpenAPI文档生成结合时，还能自动产出准确的接口说明，进一步提升协作效率。
Spring_Bootservice_layerempty_result修改时间：2026-08-17 01:06:39