沉默是金，总会发光
大家好，我是沉默
最近一次 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
public class UserService {
public User getUserById(Long id) {
User user= userMapper.selectById(id);
if (user == null) {
throw new BusinessException("用户不存在");
}
return user;
}
}
@RestController
public class UserController {
@Autowired
private UserService userService;
@GetMapping("/user/{id}")
public Result<User> getUser(@PathVariable Long id) {
return Result.success(userService.getUserById(id));
}
}
一句话：
让每一层，只关心自己的事。
第二：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());
}
}
一句话：
异常是业务失败，Result 是表现形式。
第四：单元测试，谁写谁知道
Service 返回 Result，测试写到怀疑人生
Result<User> result = userService.getUserById(1L);
assertTrue(result.isSuccess());
assertEquals("张三", result.getData().getName());
你明明是在测业务，却被迫关注响应结构。
Service 返回业务对象，测试才“纯”
Useruser= userService.getUserById(1L);
assertEquals("张三", user.getName());
测试关注点瞬间清晰。
-03-
5-7
第五：从 DDD 看，这是“层污染”
在 DDD 里：
Service / Domain 层：领域语言
Result：基础设施 / 表现层概念
如果领域层开始 return Result，本质是：
HTTP 协议污染了领域模型。
public TransferResult transfer(...) {
// 领域行为
}
这才是领域该返回的东西。
第六：接口形态一多，问题全暴露
同一个 Service，可能被：
REST 调用
GraphQL 调用
RPC 调用
如果它 return Result ——
所有接口都被强行统一成 HTTP 思维。
而返回业务对象：
Controller 想怎么包，是 Controller 的自由。
第七：事务语义，最容易被忽略的一点
@Transactional
public Order createOrder(...) {
// 失败抛异常 → 回滚
// 正常返回 → 提交
}
异常 = 回滚信号
如果你用 Result 表示失败，却不抛异常：
事务不会回滚
数据可能已经脏了
这在生产环境，是真·事故源头。
-04-
总结
那天 Code Review 结束时，我跟阿伟说了一句话：
“Service 层一旦开始返回 Result，系统的天花板就已经被你锁死了。”
阿伟沉默了几秒，说：
「我懂了……之前只是觉得‘方便’，没想过这些。」
2026 年，送你一句架构师级祝福：
愿你
少写一点“看起来省事”的代码
多写一点“五年后还能用”的设计
毕竟，
bug 和秃头，总有一个会先来。
-05-
粉丝福利
点点关注，送你互联网大厂面试题库，如果你正在找工作，又或者刚准备换工作。可以仔细阅读一下，或许对你有所帮助！
