Controller应按业务域拆分、统一响应结构、合理使用注解、严格分层解耦；如电商系统分ProductController等，返回Result泛型体，用@PathVariable/@RequestParam/@RequestBody规范参数解析，DTO加校验，Controller仅协调不写业务逻辑。
明确接口职责，按业务域划分Controller
API接口层的核心是Controller，它负责接收请求、校验参数、调用服务、封装响应。不要把所有接口堆在一个BigController里。比如电商系统，应拆分为ProductController、OrderController、UserController，每个类只处理对应领域的HTTP请求。这样代码易维护、职责清晰，也方便后续做权限控制或版本管理。
统一响应结构，避免裸对象返回
别直接return new User() 或 List
Result
private int code;
private String message;
private T data;
}
在Controller中统一用Result.success(user)或Result.fail("参数错误")返回。配合全局异常处理器（@ControllerAdvice），可自动将异常转为Result.fail，减少重复判空和try-catch。
合理使用注解，精简URL与参数解析
用@GetMapping("/users/{id}")代替拼接路径，用@PathVariable提取ID，@RequestParam接收查询参数，@RequestBody接收JSON体。注意区分：
- 简单查询条件（如page、size、keyword）→ @RequestParam
- 复杂入参（如新增用户信息）→ 封装DTO + @RequestBody
- 路径变量标识资源（如/users/123）→ @PathVariable
避免在方法参数里混用多个@RequestBody，Spring不支持。DTO要校验就加@Valid，字段上标@NotBlank、@Min等，Controller方法加BindingResult或全局处理MethodArgumentNotValidException。
分层解耦，Controller只做协调，不写业务逻辑
Controller里只调service.method()，不查数据库、不操作集合、不写if-else判断业务规则。例如“下单”接口，Controller只校验参数、转换DTO、调
用orderService.createOrder(orderDTO)，然后包装Result返回。真正的库存扣减、优惠计算、日志记录都放在Service层。这样单元测试容易写，接口变更不影响核心逻辑。
