【配置篇】告別硬編碼：多環境配置、@ConfigurationProperties與配置中心初探

摘要

本文是《Spring Boot 實戰派》系列的第五篇，聚焦于企業級應用開發中至關重要的配置管理。文章將首先解決開發、測試、生產環境配置不同的痛點，詳細介紹 Spring Boot 的 Profile（多環境配置） 機制。接著，我們將深入探討如何優雅地將配置注入到 Java Bean 中，對比 @Value 和 @ConfigurationProperties 的優劣，并重點推薦后者帶來的類型安全和代碼整潔性。最后，文章將為讀者打開一扇通往分布式配置中心（如 Nacos、Apollo）的大門，展望微服務架構下配置管理的終極解決方案。完成本章，你將掌握一套從簡單到復雜的完整配置管理策略。

系列回顧：
在上一篇中，我們為應用構建了堅不可摧的 Spring Security + JWT 安全防線。我們的應用現在既健壯又安全。但是，回想一下我們的配置文件 application.properties，里面包含了數據庫密碼、JWT 密鑰等敏感信息。如果直接提交到代碼倉庫，會帶來巨大的安全風險。更重要的是，開發環境、測試環境和生產環境的數據庫地址、服務器端口等配置通常是不同的。我們總不能每次部署都手動去修改配置文件吧？

歡迎來到配置管理的專場！

一個項目從開發者的筆記本電腦走向生產服務器的云端，會經歷多個不同的環境。如果你的配置像一盤散沙，硬編碼在代碼的各個角落，那么每一次環境切換都將是一場噩夢。

“不要硬編碼”（Don’t Hardcode）是軟件工程的基本原則之一。今天，我們將學習 Spring Boot 提供的強大工具，來徹底告別硬編碼，實現配置的外部化、結構化和動態化。我們將掌握以下核心技能：

多環境配置 (Profiles): 一份代碼，輕松應對開發、測試、生產三套不同的配置。
類型安全的配置綁定 (@ConfigurationProperties): 告別零散的 @Value 注解，用一個類優雅地承載所有相關配置。
配置中心初探: 了解為什么在微服務時代，我們需要像 Nacos 或 Apollo 這樣的配置中心。

第一站：一套代碼，走遍天下 —— 多環境配置 (Profiles)

痛點：

開發環境 (dev): 連接本地數據庫，端口 8080，開啟詳細日志。
測試環境 (test): 連接測試服務器的數據庫，端口 8081，日志級別為 INFO。
生產環境 (prod): 連接生產集群的數據庫，端口 80，關閉調試信息，JWT 密鑰更復雜。

如果只有一個 application.properties，管理這些差異會非常混亂。

解決方案：使用 Profiles 按環境隔離配置。

Spring Boot 約定，我們可以創建形如 application-{profile}.properties 的文件。其中 {profile} 就是環境的名稱。

1. 創建不同環境的配置文件

在 src/main/resources 目錄下，除了 application.properties，我們再創建兩個文件：

application-dev.properties (開發環境)
application-prod.properties (生產環境)

現在你的 resources 目錄看起來是這樣的：

src/main/resources/
├── application-dev.properties
├── application-prod.properties
└── application.properties

2. 組織你的配置

application.properties (主/公共配置文件):
存放所有環境都通用的配置。同時，也是用來激活特定環境的地方。

# --- 公共配置 ---
spring.application.name=my-first-app# --- 激活指定的環境 ---
# 默認激活 dev 環境
spring.profiles.active=dev

application-dev.properties (開發環境專屬配置):

# 開發環境服務器端口
server.port=8080# 開發環境數據庫
spring.datasource.url=jdbc:mysql://localhost:3306/springboot_db?serverTimezone=Asia/Shanghai
spring.datasource.username=root
spring.datasource.password=your_dev_password# JWT 配置
jwt.secret=this-is-a-secret-for-dev-environment
jwt.expiration-ms=3600000 # 1 hour# 開啟 SQL 日志
spring.jpa.show-sql=true

application-prod.properties (生產環境專屬配置):

# 生產環境服務器端口
server.port=80# 生產環境數據庫
spring.datasource.url=jdbc:mysql://prod-db.example.com:3306/springboot_db?serverTimezone=Asia/Shanghai
spring.datasource.username=prod_user
spring.datasource.password=a_very_strong_and_secret_password# JWT 配置
jwt.secret=${JWT_SECRET_FROM_ENV} # 從環境變量讀取，更安全
jwt.expiration-ms=86400000 # 24 hours# 關閉 SQL 日志，提升性能
spring.jpa.show-sql=false
spring.jpa.hibernate.ddl-auto=validate # 生產環境只校驗，不自動更新表結構

配置加載規則: Spring Boot 會首先加載 application.properties，然后根據 spring.profiles.active 的值，再去加載對應的 application-{profile}.properties。后加載的配置會覆蓋先加載的同名配置。

3. 如何切換環境？

有多種方式可以激活不同的 Profile，優先級從高到低：

命令行參數 (最高優先級): 這是在服務器上部署時最常用的方式。

# 啟動應用并激活 prod 環境
java -jar my-first-app-0.0.1-SNAPSHOT.jar --spring.profiles.active=prod

JVM 系統屬性:

java -Dspring.profiles.active=prod -jar my-first-app-0.0.1-SNAPSHOT.jar

環境變量:

# 先設置環境變量
export SPRING_PROFILES_ACTIVE=prod
# 再啟動應用
java -jar my-first-app-0.0.1-SNAPSHOT.jar

配置文件 application.properties (最低優先級):
如我們之前所寫，spring.profiles.active=dev。這適合作為開發時的默認配置。

第二站：優雅地讀取配置 —— `@ConfigurationProperties`

問題在哪？
回想一下我們的 JwtTokenProvider，我們是這樣讀取配置的：

@Value("${jwt.secret}")
private String jwtSecret;@Value("${jwt.expiration-ms}")
private long jwtExpirationInMs;

這種方式被稱為 @Value 注入。當只有一兩個配置項時，它還不錯。但如果一個功能有十幾個配置項（比如線程池配置、第三方服務配置），你的類里就會散落著大量的 @Value 注解，非常凌亂，且缺乏結構性。

解決方案：使用 @ConfigurationProperties 進行類型安全的配置綁定。

@ConfigurationProperties 可以將配置文件中以某個前綴開頭的一組屬性，直接映射到一個 Java 對象上。

1. 創建一個配置屬性類

我們來為 JWT 的配置創建一個專門的類。在 config 包下創建 JwtProperties.java:

package com.example.myfirstapp.config;import org.springframework.boot.context.properties.ConfigurationProperties;
import org.springframework.stereotype.Component;@Component
@ConfigurationProperties(prefix = "jwt") // 綁定前綴為 "jwt" 的配置
public class JwtProperties {/*** JWT 密鑰，用于簽名*/private String secret;/*** Token 過期時間，單位：毫秒*/private Long expirationMs;// --- Getters and Setters ---// 必須提供 Getter 和 Setter，Spring Boot 才能注入值public String getSecret() { return secret; }public void setSecret(String secret) { this.secret = secret; }public Long getExpirationMs() { return expirationMs; }public void setExpirationMs(Long expirationMs) { this.expirationMs = expirationMs; }
}

注意： Spring Boot 會自動將 kebab-case（如 expiration-ms）或 snake_case（如 expiration_ms）的配置名，映射到駝峰式（camelCase）的字段名 expirationMs 上。

2. 在需要的地方注入配置類

現在，改造 JwtTokenProvider，不再使用 @Value，而是直接注入 JwtProperties 對象。

package com.example.myfirstapp.config;// ... imports ...@Component
public class JwtTokenProvider {// ... logger ...private final JwtProperties jwtProperties;private Key key;// 推薦使用構造器注入@Autowiredpublic JwtTokenProvider(JwtProperties jwtProperties) {this.jwtProperties = jwtProperties;}@PostConstructpublic void init() {this.key = Keys.hmacShaKeyFor(jwtProperties.getSecret().getBytes());}public String generateToken(User user) {Date now = new Date();Date expiryDate = new Date(now.getTime() + jwtProperties.getExpirationMs());// ... build token ...}// ...其他方法...
}

@ConfigurationProperties vs @Value

特性	`@ConfigurationProperties`	`@Value`
功能	批量注入，結構化	單個值注入
類型安全	強大，綁定時自動轉換類型	弱，只是字符串替換
代碼整潔	非常整潔，配置與業務邏輯分離	容易造成代碼散亂
校驗	支持 JSR 303 校驗 (e.g., `@Validated`)	不支持
推薦場景	所有業務配置	注入單個系統屬性或簡單值

結論： 優先使用 @ConfigurationProperties，它能讓你的代碼更健壯、更易于維護。

第三站：未來的方向 —— 配置中心初探

問題在哪？
我們目前實現的配置管理已經很不錯了，但它仍然有局限：

修改配置需要重啟： 如果你想調整生產環境的日志級別，或者修改一個功能開關，你必須修改配置文件，然后重新打包、部署、重啟應用。在微服務架構下，這可能是幾十上百個服務的重啟，代價巨大。
配置分散： 每個微服務都有自己的一套配置文件，難以集中管理和審計。

解決方案：使用分布式配置中心。

配置中心是一個獨立的服務，所有的應用啟動時都去配置中心拉取自己的配置。

工作流程：

開發者/運維人員在配置中心（如 Nacos、Apollo）的 Web 界面上，為每個應用、每個環境維護配置。
應用啟動時，不再讀取本地的 application.properties，而是向配置中心注冊，并拉取屬于自己的配置。
核心優勢： 當你在配置中心修改了某個配置項并發布后，配置中心會主動通知所有監聽該配置的應用。應用收到通知后，無需重啟，就能動態刷新內存中的配置，實現配置的熱更新。

主流配置中心：