为什么我不允许 Service 层直接返回 Result？

沉默是金，总会发光

大家好，我是沉默

最近一次 Code Review，我和阿伟“打”了一架。

事情的起因很简单。
我发现他在Service 层直接 return 了 Result 对象。

我提醒了一句：“这个不太合适。”

阿伟一脸疑惑地反问我：

「为啥不行？这样 Controller 直接 return，不是更省事吗？」

于是，一场看似很小、但含金量极高的技术 battle就此展开。

聊着聊着我才意识到：
这个问题，几乎每个写过三年以上 Java 的人都“踩过”，但真正想明白的人并不多。

所以我决定把这次讨论完整拆出来
不止告诉你“不该这么写”，而是告诉你：为什么。

知其然，更要知其所以然。
耐心看完，你一定会对「分层设计」有一次质变级的理解。

-01-

先抛结论

Service 层返回 Result，本质上是在“越权”。

它越过了自己的职责边界，开始关心HTTP 返回结构、错误码、响应格式
而这些，本就不该是它操心的事。

我们一点一点拆。

-02-

1-4

第一：职责分离，被悄悄破坏了

在最经典的 MVC / 分层架构里：

Controller：处理 HTTP、参数、响应格式
Service：只干一件事，业务逻辑
DAO / Repository：数据访问

但很多项目，会慢慢演变成这样

不推荐的写法

@Service public class UserService { public Result<User> getUserById(Long id) { User user= userMapper.selectById(id); if (user == null) { return Result.error(404, "用户不存在"); } return Result.success(user); } }

@RestController public class UserController { @Autowired private UserService userService; @GetMapping("/user/{id}") public Result<User> getUser(@PathVariable Long id) { return userService.getUserById(id); } }

表面看：
代码少
Controller 很“干净”

但问题在于：

Service 层已经开始关心：错误码、返回结构、前端展示。

一旦哪天你要：

改返回格式
统一错误码
接 GraphQL / RPC
做内部服务复用

你会发现
改动像病毒一样，扩散到所有 Service 方法。

第二：Service 返回 Result，复用性直接废掉

这个坑，在服务之间互相调用时，尤为明显。

Service 返回 Result 时，调用方会很痛苦

@Service public class OrderService { @Autowired private UserService userService; public void createOrder(Long userId) { Result<User> userResult =

userService.getUserById(userId); if (!userResult.isSuccess()) { throw new BusinessException(userResult.getMessage()); } User user= userResult.getData(); // 后续逻辑 } }

你会发现两个很烦的点：

1. 得解包 Result
2. 得理解 Result 的语义（success？code？message？）

但本质上，OrderService 只关心一件事：User 在不在。

Service 返回业务对象，调用才“像业务”

@Service public class OrderService { @Autowired private UserService userService; public void createOrder(Long userId) { User user= userService.getUserById(userId); // 后续逻辑 } }

业务层之间，应该传“业务语言”，而不是 HTTP 响应协议。

第三：异常 vs Result，决定了系统的上限

很多人喜欢在 Service 里这样写：

public Result<Void> createOrder(Long userId) { if (userId == null) { return Result.fail("用户ID不能为空"); } return Result.success(); }

短期看没问题，长期看：

错误处理逻辑到处都是
统一改异常策略成本极高
日志、堆栈信息丢失

正确姿势：异常 + 全局处理

public void createOrder(Long userId) { if (userId == null) { throw new BusinessException("用户ID不能为空"); } }

@RestControllerAdvice public class GlobalExceptionHandler { @ExceptionHandler(BusinessException.class) public Result<Void> handle(BusinessException e) { return Result.error(400, e.getMessage()); } }

一句话：