告別低效代碼！優(yōu)化 Spring Boot 編程的關(guān)鍵策略大公開(kāi)
說(shuō)實(shí)話(huà)，我非常喜歡 Spring Boot。它簡(jiǎn)化了開(kāi)發(fā)流程，特別是快速原型開(kāi)發(fā)方面。然而，經(jīng)過(guò)三年接手別人“快速原型”代碼的經(jīng)歷，我不得不說(shuō)一些心里話(huà)。
雖然沒(méi)有一種“最佳”方式來(lái)編寫(xiě) Spring Boot 應(yīng)用，但你絕不能把所有的業(yè)務(wù)邏輯都堆積在控制器里。不是一部分，而是所有的邏輯——300 行的控制器方法，里面既有數(shù)據(jù)庫(kù)查詢(xún)、發(fā)送郵件、文件處理，甚至可能夾雜著一些購(gòu)物清單。
如果你正這么做，拜托，停下吧。你的同事們已經(jīng)在你背后討論你了，而討論內(nèi)容肯定不是什么好事。
那么，如何編寫(xiě) Spring Boot 代碼，避免讓同事們對(duì)你的生活選擇產(chǎn)生質(zhì)疑呢？以下是我總結(jié)的幾個(gè)關(guān)鍵點(diǎn)。
一、避免包結(jié)構(gòu)混亂
我曾看到一些 Spring Boot 項(xiàng)目，項(xiàng)目里的所有代碼都被塞進(jìn)了一個(gè)包里。控制器、實(shí)體類(lèi)、工具類(lèi)都混在一起，簡(jiǎn)直像是颶風(fēng)經(jīng)過(guò)的場(chǎng)景，什么都被打亂了。就像走進(jìn)別人家，結(jié)果發(fā)現(xiàn)廚房里竟然放著內(nèi)衣一樣。
合理的包結(jié)構(gòu)應(yīng)該是這樣的：
com/yourcompany/yourapp
├── config/ # Spring 配置類(lèi)
├── controller/ # HTTP 處理
├── service/ # 業(yè)務(wù)邏輯
├── repository/ # 數(shù)據(jù)庫(kù)操作
├── model/ # 數(shù)據(jù)模型
├── exception/ # 自定義異常
└── util/ # 輔助方法這樣做的目的是讓代碼結(jié)構(gòu)更清晰，當(dāng)你想要了解用戶(hù)注冊(cè)功能時(shí)，不用到處找，直接去 service 層查看即可。
控制器 只負(fù)責(zé)處理 HTTP 請(qǐng)求和響應(yīng)，任何業(yè)務(wù)邏輯都應(yīng)該放在服務(wù)層（Service）。如果你在控制器里寫(xiě)了 SQL 查詢(xún)、發(fā)送郵件或做文件處理，那就是錯(cuò)的。
二、避免在字段上使用 @Autowired
每次看到下面這種代碼，我的眼睛就開(kāi)始發(fā)抖：
@Service
public class UserService {
@Autowired
private UserRepository userRepository; // 錯(cuò)誤
@Autowired
private EmailService emailService; // 停止這樣
@Autowired
private PasswordEncoder encoder; // 這樣做根本不行
}這種寫(xiě)法的最大問(wèn)題是，無(wú)法有效測(cè)試。你只能進(jìn)行集成測(cè)試，這樣不僅慢，還可能導(dǎo)致 Spring 在測(cè)試環(huán)境下出錯(cuò)。
正確的寫(xiě)法應(yīng)該是：
@Service
public class UserService {
private final UserRepository userRepository;
private final EmailService emailService;
private final PasswordEncoder encoder;
public UserService(UserRepository userRepository,
EmailService emailService,
PasswordEncoder encoder) {
this.userRepository = userRepository;
this.emailService = emailService;
this.encoder = encoder;
}
}這樣做的好處是，代碼的依賴(lài)關(guān)系變得顯式，類(lèi)變成了不可變的，并且可以輕松地進(jìn)行單元測(cè)試。
三、避免配置混亂
我曾經(jīng)參與過(guò)一個(gè)項(xiàng)目，配置值像是散落在各個(gè)地方：
- 屬性文件
- 環(huán)境變量
- 代碼中的硬編碼字符串
- 從 StackOverflow 拿來(lái)的隨機(jī) JSON 文件
- 甚至可能是某些史前的壁畫(huà)……
不要成為那種人。
正確的做法：
將配置集中在 application.yml 中，并使用 @ConfigurationProperties 來(lái)映射配置值：
# application.yml
server:
port: ${SERVER_PORT:8080}
app:
name: ${APP_NAME:MyAwesomeApp}
email:
enabled: ${EMAIL_ENABLED:true}
smtp-host: ${SMTP_HOST:localhost}
from-address: ${FROM_EMAIL:noreply@example.com}然后，創(chuàng)建一個(gè)配置類(lèi)來(lái)管理這些配置：
@ConfigurationProperties(prefix = "app")
@Data
@Component
public class AppConfig {
private String name;
private Email email = new Email();
@Data
public static class Email {
private boolean enabled = true;
private String smtpHost = "localhost";
private String fromAddress = "noreply@example.com";
}
}這種做法將使你的 IDE 更喜歡你，你的部署腳本也會(huì)更順利，調(diào)試代碼的人會(huì)感謝你。
四、控制器不應(yīng)成為“神對(duì)象”
我曾在生產(chǎn)代碼中看到這樣一個(gè)控制器方法：
@PostMapping("/users")
public ResponseEntity<?> createUser(@RequestBody Map<String, Object> request) {
// 47行驗(yàn)證邏輯
// 23行數(shù)據(jù)庫(kù)查詢(xún)
// 15行發(fā)送郵件
// 8行文件處理
// 1行 HTTP 響應(yīng)
return ResponseEntity.ok("User created maybe?");
}這不應(yīng)該是一個(gè)控制器方法，而是一個(gè)小小說(shuō)。控制器應(yīng)保持簡(jiǎn)潔，專(zhuān)注于請(qǐng)求和響應(yīng)。所有的業(yè)務(wù)邏輯應(yīng)該移到服務(wù)層。
正確的做法：
@RestController
@RequestMapping("/api/v1/users")
public class UserController {
private final UserService userService;
public UserController(UserService userService) {
this.userService = userService;
}
@PostMapping
public ResponseEntity<UserResponse> createUser(@Valid @RequestBody CreateUserRequest request) {
User user = userService.createUser(request);
UserResponse response = UserResponse.from(user);
return ResponseEntity.status(HttpStatus.CREATED).body(response);
}
@GetMapping("/{id}")
public ResponseEntity<UserResponse> getUser(@PathVariable Long id) {
return userService.findById(id)
.map(user -> ResponseEntity.ok(UserResponse.from(user)))
.orElse(ResponseEntity.notFound().build());
}
}如你所見(jiàn)，代碼簡(jiǎn)潔明了，做到了“無(wú)聊”的控制器邏輯，這是好代碼。
五、異常處理和日志記錄
沒(méi)有什么比 API 響應(yīng)中隨意泄露異常堆棧更能證明你的代碼不成熟了。用戶(hù)并不關(guān)心你在 UserServiceImpl.java 第47行遇到的 NullPointerException。
正確做法：
使用 @RestControllerAdvice 來(lái)進(jìn)行全局異常處理：
@RestControllerAdvice
public class GlobalExceptionHandler {
private static final Logger log = LoggerFactory.getLogger(GlobalExceptionHandler.class);
@ExceptionHandler(UserNotFoundException.class)
public ResponseEntity<ErrorResponse> handleUserNotFound(UserNotFoundException ex) {
log.info("User not found: {}", ex.getMessage());
return ResponseEntity.status(HttpStatus.NOT_FOUND)
.body(new ErrorResponse("USER_NOT_FOUND", "User not found"));
}
@ExceptionHandler(Exception.class)
public ResponseEntity<ErrorResponse> handleGeneral(Exception ex) {
log.error("Unexpected error", ex);
return ResponseEntity.status(HttpStatus.INTERNAL_SERVER_ERROR)
.body(new ErrorResponse("INTERNAL_ERROR", "Something went wrong"));
}
}這種方式能夠確保異常處理的統(tǒng)一性，且能避免將錯(cuò)誤堆棧暴露給最終用戶(hù)。
結(jié)論
Spring Boot 是一個(gè)非常棒的框架，使用得當(dāng)時(shí)，能夠極大提升開(kāi)發(fā)效率。然而，它并不能修復(fù)不良的架構(gòu)、糟糕的錯(cuò)誤處理或缺乏單元測(cè)試的代碼。作為開(kāi)發(fā)人員，我們的任務(wù)是編寫(xiě)可維護(hù)、可擴(kuò)展的代碼，而不是僅僅完成任務(wù)。
記住，編寫(xiě)代碼時(shí)，想一想“未來(lái)的自己”和維護(hù)這些代碼的同事。不要讓你的代碼變成維護(hù)的地獄。遵循上述最佳實(shí)踐，你的同事和未來(lái)的你都會(huì)感激你的。
