核心内容摘要
XL上司令第一季：未删减的震撼，未曾改变的传奇
沉默是金总会发光大家好我是沉默最近一次 Code Review我和阿伟“打”了一架。
事情的起因很简单。
我发现他在Service 层直接 return 了 Result 对象。
我提醒了一句“这个不太合适。
”阿伟一脸疑惑地反问我「为啥不行这样 Controller 直接 return不是更省事吗」于是一场看似很小、但含金量极高的技术 battle就此展开。
聊着聊着我才意识到这个问题几乎每个写过三年以上 Java 的人都“踩过”但真正想明白的人并不多。
所以我决定把这次讨论完整拆出来不止告诉你“不该这么写”而是告诉你为什么。
知其然更要知其所以然。
耐心看完你一定会对「分层设计」有一次质变级的理解。
-01-先抛结论Service 层返回 Result本质上是在“越权”。
它越过了自己的职责边界开始关心HTTP 返回结构、错误码、响应格式而这些本就不该是它操心的事。
我们一点一点拆。
-
第一职责分离被悄悄破坏了在最经典的 MVC / 分层架构里Controller处理 HTTP、参数、响应格式Service只干一件事 业务逻辑DAO / Repository数据访问但很多项目会慢慢演变成这样不推荐的写法Servicepublic class UserService {public ResultUser getUserById(Long id) {User user userMapper.selectById(id);if (user null) {return Result.error(404, 用户不存在);}return Result.success(user);}}RestControllerpublic class UserController {Autowiredprivate UserService userService;GetMapping(/user/{id})public ResultUser getUser(PathVariable Long id) {return userService.getUserById(id);}}表面看代码少Controller 很“干净”但问题在于Service 层已经开始关心错误码、返回结构、前端展示。
一旦哪天你要改返回格式统一错误码接 GraphQL / RPC做内部服务复用你会发现改动像病毒一样扩散到所有 Service 方法。
推荐的写法Servicepublic class UserService {public User getUserById(Long id) {User user userMapper.selectById(id);if (user null) {throw new BusinessException(用户不存在);}return user;}}RestControllerpublic class UserController {Autowiredprivate UserService userService;GetMapping(/user/{id})public ResultUser getUser(PathVariable Long id) {return Result.success(userService.getUserById(id));}}一句话让每一层只关心自己的事。
第二Service 返回 Result复用性直接废掉这个坑在服务之间互相调用时尤为明显。
Service 返回 Result 时调用方会很痛苦Servicepublic class OrderService {Autowiredprivate UserService userService;public void createOrder(Long userId) {ResultUser userResult userService.getUserById(userId);if (!userResult.isSuccess()) {throw new BusinessException(userResult.getMessage());}User user userResult.getData();// 后续逻辑}}你会发现两个很烦的点
得解包 Result
得理解 Result 的语义successcodemessage但本质上OrderService 只关心一件事User 在不在。
Service 返回业务对象调用才“像业务”Servicepublic class OrderService {Autowiredprivate UserService userService;public void createOrder(Long userId) {User user userService.getUserById(userId);// 后续逻辑}}业务层之间应该传“业务语言”而不是 HTTP 响应协议。
第三异常 vs Result决定了系统的上限很多人喜欢在 Service 里这样写public ResultVoid 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不能为空);}}RestControllerAdvicepublic class GlobalExceptionHandler {ExceptionHandler(BusinessException.class)public ResultVoid handle(BusinessException e) {return Result.error(400, e.getMessage());}}一句话异常是业务失败Result 是表现形式。
第四单元测试谁写谁知道Service 返回 Result测试写到怀疑人生ResultUser result userService.getUserById(1L);assertTrue(result.isSuccess());assertEquals(张三, result.getData().getName());你明明是在测业务却被迫关注响应结构。
Service 返回业务对象测试才“纯”Useruser userService.getUserById(1L);assertEquals(张三, user.getName());测试关注点瞬间清晰。
-
第五从 DDD 看这是“层污染”在 DDD 里Service / Domain 层领域语言Result基础设施 / 表现层概念如果领域层开始 return Result本质是HTTP 协议污染了领域模型。
public TransferResult transfer(...) {// 领域行为}这才是领域该返回的东西。
第六接口形态一多问题全暴露同一个 Service可能被REST 调用GraphQL 调用RPC 调用如果它 return Result ——所有接口都被强行统一成 HTTP 思维。
而返回业务对象Controller 想怎么包是 Controller 的自由。
第七事务语义最容易被忽略的一点Transactionalpublic Order createOrder(...) {// 失败抛异常 → 回滚// 正常返回 → 提交}异常 回滚信号如果你用 Result 表示失败却不抛异常事务不会回滚数据可能已经脏了这在生产环境是真·事故源头。
-04-
总结那天 Code Review 结束时我跟阿伟说了一句话“Service 层一旦开始返回 Result系统的天花板就已经被你锁死了。
”阿伟沉默了几秒说「我懂了……之前只是觉得‘方便’没想过这些。
」2026 年送你一句架构师级祝福愿你少写一点“看起来省事”的代码多写一点“五年后还能用”的设计毕竟bug 和秃头总有一个会先来。
-05-粉丝福利点点关注送你互联网大厂面试题库如果你正在找工作又或者刚准备换工作。
可以仔细阅读一下或许对你有所帮助