在Spring的@RestController单方法中调用两个不同@Service是否为不良实践？

这绝对算不上不良开发实践——甚至在很多场景下是完全合理的常规操作！

为什么你的写法是合理的？ #

Controller层的核心职责本来就是协调不同的业务服务，把多个服务的结果整合后，按照前端需要的格式返回响应。你这里的UserController逻辑非常清晰：

1. 先通过UserService验证用户是否存在（避免返回“不存在用户的帖子”这种不符合预期的结果）
2. 再调用PostService获取该用户的帖子列表
3. 封装成标准的响应返回

完全符合MVC分层架构的设计思路，没有任何问题。

需要注意的几个小细节（帮你优化代码） #

虽然当前写法没问题，但有几个可以改进的地方：

• 去掉冗余的null判断：你的UserService.findById()方法在找不到用户时已经抛出了UserNotFoundException，所以Controller里不需要再判断user != null，直接调用方法即可，异常会被Spring的异常处理机制捕获并处理。
• 优先使用构造函数注入：@Autowired字段注入虽然能用，但构造函数注入（或者用Lombok的@RequiredArgsConstructor简化）更利于单元测试，也能保证依赖不可变，代码更健壮。

优化后的UserController代码可以改成这样：

@RestController
@RequiredArgsConstructor
public class UserController {
    private final UserService userService;
    private final PostService postService;
    
    @GetMapping("/users/{id}/posts")
    public ResponseEntity<List<Post>> retrieveAllPostsByUserId(@PathVariable("id") Long userId) throws UserNotFoundException {
        // 直接调用，找不到用户会自动抛出异常
        userService.findById(userId);
        List<Post> posts = postService.findPostsByUserId(userId);
        return ResponseEntity.ok(posts);
    }
}

什么时候需要警惕？ #

只有当你在Controller里直接编写业务逻辑时，才属于不良实践。比如：

• 在Controller里过滤帖子的敏感内容
• 计算用户帖子的统计数据
• 处理多个服务的写操作却不考虑事务一致性

这些逻辑都应该封装到Service层（甚至可以新增一个专门的UserPostService来整合这两个操作），让Controller只专注于请求响应的处理。

总的来说，你的当前写法是完全合规的，放心用就好！

内容的提问来源于stack exchange，提问作者Matheus