为什么我不允许 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();
       // 后续逻辑
    }
}

你会发现两个很烦的点：

得解包 Result
得理解 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-

粉丝福利