Spring Boot 開發中有七件事，你必須知道
環境：SpringBoot3.2.5
1. 簡介
這篇文章將逐一探討在SpringBoot開發中容易被忽視的7個關鍵細節，從而避免開發過程中的陷阱。
無論是你是初學者還是有經驗的開發者，關注這些小細節往往能夠預防許多常見問題，同時提高開發效率，減少開發過程中的重復工作，甚至可能提升所開發產品的質量。
2. 核心關鍵點
2.1 字段避免@Autowired注入
@Autowired可以將依賴注入到組件中，但過度使用它可能會導致緊密的耦合和測試困難。使用構造器注入或@Resource等方法可以使依賴關系更加清晰。
推薦做法：
優先使用構造器注入，因為它可以清晰地定義組件的依賴，并且在單元測試中更容易進行模擬（mock）。
如果你當前使用了Lombok，你可以利用@RequiredArgsConstructor注解來自動生成構造器。
private final UserRepository userRepository ;
public UserService(UserRepository userRepository) {
this.userRepository = userRepository ;
}我們是禁止使用Lombok的。
最后，我還是推薦使用構造函數注入，避免字段上使用@Autowired / @Resource注解，并且Spring官方推薦的也是構造函數注入。
2.2 避免在控制器中編寫業務邏輯
嚴格來說，Controller控制器僅負責處理HTTP請求和響應。業務邏輯應放置在其他層（如Service層）。將業務邏輯與請求和響應處理混合在一起對編寫單元測試非常不利。如果將業務邏輯移動到服務層，那么單元測試可以更加針對服務層進行。
推薦做法：
將業務邏輯移動到服務層（Service），并讓控制器僅處理請求并調用服務方法。進行這種分離后，不僅單元測試更加方便，代碼也更容易重用。
@RestController
@RequestMapping("/products")
public class ProductController {
private final ProductService productService ;
public ProductController(ProductService productService) {
this.productService = productService ;
}
@GetMapping("/{id}")
public ResponseEntity<Product> getProduct(@PathVariable Long id) {
// 調用Service進行業務邏輯的處理
Product product = productService.getProductById(id) ;
return ResponseEntity.ok(product) ;
}
}這也是我們日常開發中最基本的要求了。
2.3 使用@ConfigurationProperties替代@Value
使用@Value注解來獲取配置雖然簡單，但缺乏結構性。此外，過度使用會導致@Value注解散布在整個項目中，這不利于代碼的維護和重用。使用@ConfigurationProperties可以避免這些問題，使配置更清晰、更易于管理。
推薦做法：
創建一個專用的配置類，并使用@ConfigurationProperties注解來綁定相關的配置項，這增強了代碼的可讀性。當在多個地方使用相同的配置類時，它有助于避免重復配置屬性，從而提高了代碼的可重用性。這種方法還使配置更具結構性，便于維護和理解。
例如，在應用配置的情況下，當處理大量屬性或復雜配置結構時，@ConfigurationProperties所提供的便利性和長期影響遠遠超過了創建一個新類所需的工作量。
@ConfigurationProperties(prefix = "pack.app")
public class AppConfig {
private String title ;
private String version ;
private Integer uid ;
// getters and setters
}2.4 避免構造函數過于復雜
構造器應盡可能保持簡單。做過多的初始化工作會使構造器變得復雜且難以理解。此外，如果構造器中做了太多工作，未來的需求變更很可能需要頻繁修改，從而增加了代碼維護的難度。它還顯著影響性能，因為在對象創建期間執行了復雜操作。
推薦做法：
主要使用構造器進行依賴注入，并將初始化工作移動到用@PostConstruct注解的方法中或在服務方法內執行。如果必須在構造器中執行大量操作，考慮實現延遲加載或將其轉換為工廠模式。
public class CommonComponent {
private final CommonService commonService ;
public CommonComponent(CommonService commonService) {
this.commonService = commonService ;
}
@PostConstruct
public void init() {
// TODO
}
}構造器只做基本的注入操作。其它初始化的工作通過@PostConstruct注解的方法來處理。
2.5 定義不同的環境配置文件
為不同環境（開發、測試、生產）使用不同的配置有助于隔離環境差異。
推薦做法：
使用application-{profile}.properties或application-{profile}.yml來為每個環境定義配置。
激活不同的配置文件：
spring:
profiles:
active:
- dev2.6 使用異常替代返回值
首先，先來看段代碼：
@Service
public class ProductService {
private final ProductRepository productRepository ;
public ProductService(ProductRepository productRepository) {
this.productRepository = productRepository ;
}
public R<Product, String> queryById(Long id) {
Optional<Product> opt = productRepository.findById(id) ;
if (opt.isPresent()) {
return R.success(opt.get()) ;
} else {
return R.error("商品不存在id: " + id) ;
}
}
}上面代碼直接使用R作為方法的返回值顯得不夠優雅。
如果將返回R.error的部分替換為拋出new XXException異常，這不僅能提高代碼的可讀性，還能讓服務返回業務結果，而不是與控制器結果糾纏在一起。
優化代碼：
@Service
public class ProductService {
private final ProductRepository productRepository ;
public ProductService(ProductRepository productRepository) {
this.productRepository = productRepository ;
}
public Product queryById(Long id) {
return productRepository.findById(id)
.orElseThrow(() -> new ProductNotFoundException("商品不存在id: " + id));
}
}Service層應該只返回業務結果，而不應涉及控制器的結果。此外，拋出的異常可以讓維護人員立即理解，并指出問題所在。
最后，我們利用@RestControllerAdvice注解來進行全局異常處理，以便及時捕獲業務邏輯中拋出的異常，避免500錯誤，如下示例：
@RestControllerAdvice
public class GlobalExceptionHandler {
@ExceptionHandler(ProductNotFoundException.class)
public ResponseEntity<ErrorResponse> handleProductNotFoundException(ProductNotFoundException ex) {
ErrorResponse errorResponse = new ErrorResponse(HttpStatus.NOT_FOUND.value(), ex.getMessage()) ;
return new ResponseEntity<>(errorResponse, HttpStatus.NOT_FOUND) ;
}
// 其它異常處理句柄
}有人可能會說這種拋異常處理方式是反模式設計，你覺得呢？
2.7 優先考慮ResponseEntity作為響應
很多人會自定義對象作為Controller接口返回的統一對象，但SpringBoot本身提供了一個專門的響應實體，即ResponseEntity。
ResponseEntity提供了更大的靈活性，允許控制響應的各個方面，包括HTTP狀態碼、響應頭、響應體等。這使得程序能夠更精確地構建響應結果，根據業務需求返回不同的HTTP狀態碼。
此外，ResponseEntity還支持泛型，允許返回不同類型的響應體，滿足各種業務場景下的響應需求。
下面是ResponseEntity API文檔說明：
圖片
這點并非必須遵守，當你確實需要高度定制化，那么使用自定義的結果對象也當然沒有問題。
