環(huán)境：SpringBoot3.2.5

1. 簡介

這篇文章將逐一探討在SpringBoot開發(fā)中容易被忽視的7個關(guān)鍵細節(jié)，從而避免開發(fā)過程中的陷阱。

無論是你是初學(xué)者還是有經(jīng)驗的開發(fā)者，關(guān)注這些小細節(jié)往往能夠預(yù)防許多常見問題，同時提高開發(fā)效率，減少開發(fā)過程中的重復(fù)工作，甚至可能提升所開發(fā)產(chǎn)品的質(zhì)量。

2. 核心關(guān)鍵點

2.1 字段避免@Autowired注入

@Autowired可以將依賴注入到組件中，但過度使用它可能會導(dǎo)致緊密的耦合和測試困難。使用構(gòu)造器注入或@Resource等方法可以使依賴關(guān)系更加清晰。

推薦做法：

優(yōu)先使用構(gòu)造器注入，因為它可以清晰地定義組件的依賴，并且在單元測試中更容易進行模擬（mock）。

如果你當前使用了Lombok，你可以利用@RequiredArgsConstructor注解來自動生成構(gòu)造器。

private final UserRepository userRepository ;
public UserService(UserRepository userRepository) {
  this.userRepository = userRepository ;
}

我們是禁止使用Lombok的。

最后，我還是推薦使用構(gòu)造函數(shù)注入，避免字段上使用@Autowired / @Resource注解，并且Spring官方推薦的也是構(gòu)造函數(shù)注入。

2.2 避免在控制器中編寫業(yè)務(wù)邏輯

嚴格來說，Controller控制器僅負責處理HTTP請求和響應(yīng)。業(yè)務(wù)邏輯應(yīng)放置在其他層（如Service層）。將業(yè)務(wù)邏輯與請求和響應(yīng)處理混合在一起對編寫單元測試非常不利。如果將業(yè)務(wù)邏輯移動到服務(wù)層，那么單元測試可以更加針對服務(wù)層進行。

推薦做法：

將業(yè)務(wù)邏輯移動到服務(wù)層（Service），并讓控制器僅處理請求并調(diào)用服務(wù)方法。進行這種分離后，不僅單元測試更加方便，代碼也更容易重用。

@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) {
    // 調(diào)用Service進行業(yè)務(wù)邏輯的處理
    Product product = productService.getProductById(id) ;
    return ResponseEntity.ok(product) ;
  }
}

這也是我們?nèi)粘ｉ_發(fā)中最基本的要求了。

2.3 使用@ConfigurationProperties替代@Value

使用@Value注解來獲取配置雖然簡單，但缺乏結(jié)構(gòu)性。此外，過度使用會導(dǎo)致@Value注解散布在整個項目中，這不利于代碼的維護和重用。使用@ConfigurationProperties可以避免這些問題，使配置更清晰、更易于管理。

推薦做法：

創(chuàng)建一個專用的配置類，并使用@ConfigurationProperties注解來綁定相關(guān)的配置項，這增強了代碼的可讀性。當在多個地方使用相同的配置類時，它有助于避免重復(fù)配置屬性，從而提高了代碼的可重用性。這種方法還使配置更具結(jié)構(gòu)性，便于維護和理解。

例如，在應(yīng)用配置的情況下，當處理大量屬性或復(fù)雜配置結(jié)構(gòu)時，@ConfigurationProperties所提供的便利性和長期影響遠遠超過了創(chuàng)建一個新類所需的工作量。

@ConfigurationProperties(prefix = "pack.app")
public class AppConfig {
  private String title ;
  private String version ;
  private Integer uid ;
  // getters and setters
}

2.4 避免構(gòu)造函數(shù)過于復(fù)雜

構(gòu)造器應(yīng)盡可能保持簡單。做過多的初始化工作會使構(gòu)造器變得復(fù)雜且難以理解。此外，如果構(gòu)造器中做了太多工作，未來的需求變更很可能需要頻繁修改，從而增加了代碼維護的難度。它還顯著影響性能，因為在對象創(chuàng)建期間執(zhí)行了復(fù)雜操作。

推薦做法：

主要使用構(gòu)造器進行依賴注入，并將初始化工作移動到用@PostConstruct注解的方法中或在服務(wù)方法內(nèi)執(zhí)行。如果必須在構(gòu)造器中執(zhí)行大量操作，考慮實現(xiàn)延遲加載或?qū)⑵滢D(zhuǎn)換為工廠模式。

public class CommonComponent {
  private final CommonService commonService ;


  public CommonComponent(CommonService commonService) {
    this.commonService = commonService ;
  }


  @PostConstruct
  public void init() {
    // TODO
  }
}

構(gòu)造器只做基本的注入操作。其它初始化的工作通過@PostConstruct注解的方法來處理。

2.5 定義不同的環(huán)境配置文件

為不同環(huán)境（開發(fā)、測試、生產(chǎn)）使用不同的配置有助于隔離環(huán)境差異。

推薦做法：

使用application-{profile}.properties或application-{profile}.yml來為每個環(huán)境定義配置。

激活不同的配置文件：

spring:
  profiles:
    active:
    - dev

2.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作為方法的返回值顯得不夠優(yōu)雅。

如果將返回R.error的部分替換為拋出new XXException異常，這不僅能提高代碼的可讀性，還能讓服務(wù)返回業(yè)務(wù)結(jié)果，而不是與控制器結(jié)果糾纏在一起。

優(yōu)化代碼：

@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層應(yīng)該只返回業(yè)務(wù)結(jié)果，而不應(yīng)涉及控制器的結(jié)果。此外，拋出的異?？梢宰尵S護人員立即理解，并指出問題所在。

最后，我們利用@RestControllerAdvice注解來進行全局異常處理，以便及時捕獲業(yè)務(wù)邏輯中拋出的異常，避免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) ;
  }
  // 其它異常處理句柄
}

有人可能會說這種拋異常處理方式是反模式設(shè)計，你覺得呢？

2.7 優(yōu)先考慮ResponseEntity作為響應(yīng)

很多人會自定義對象作為Controller接口返回的統(tǒng)一對象，但SpringBoot本身提供了一個專門的響應(yīng)實體，即ResponseEntity。

ResponseEntity提供了更大的靈活性，允許控制響應(yīng)的各個方面，包括HTTP狀態(tài)碼、響應(yīng)頭、響應(yīng)體等。這使得程序能夠更精確地構(gòu)建響應(yīng)結(jié)果，根據(jù)業(yè)務(wù)需求返回不同的HTTP狀態(tài)碼。

此外，ResponseEntity還支持泛型，允許返回不同類型的響應(yīng)體，滿足各種業(yè)務(wù)場景下的響應(yīng)需求。

下面是ResponseEntity API文檔說明：

圖片

這點并非必須遵守，當你確實需要高度定制化，那么使用自定義的結(jié)果對象也當然沒有問題。