3、配置管理基础：配置项、配置来源、配置格式（如YAML、JSON、Properties）

3.1 配置项：最小粒度的配置单元

配置项（Configuration Item）是配置管理中最基础的概念，它指一个可独立命名、可独立取值、可独立追踪的配置单元。在企业级系统中，一个配置项通常由键（Key）与值（Value）组成，并附带元数据（如所属环境、生效版本、变更时间）。理解配置项的粒度至关重要——粒度过粗会导致多个逻辑含义耦合在同一个键中，粒度过细则造成配置爆炸。

例如，一个数据库连接配置不应写成 db=mysql://10.0.0.1:3306/app?user=root&password=123 这样的“大杂烩”字符串，而应拆分为 db.host、db.port、db.name、db.username、db.password 等独立配置项。这样拆分后，运维人员可以单独调整端口或切换数据库实例，而不必重写整个连接串，也便于在配置中心进行细粒度权限控制。

3.2 配置来源：从本地文件到分布式配置中心

配置来源决定了配置项的存储位置与加载优先级。在企业级应用中，配置来源通常按以下层次排列（优先级从高到低）：

1. 环境变量：由操作系统或容器注入，适合存放部署相关的敏感信息（如密码、密钥），但难以批量管理。
2. 命令行参数：在进程启动时通过 --key=value 传入，适合临时覆盖，不适合持久化。
3. 外部配置中心：如 Apollo、Nacos、Spring Cloud Config，支持动态刷新、版本回滚、权限审计，是微服务架构下的主流选择。
4. 本地配置文件：如 application.yml、config.properties，随应用打包，适合默认值或开发环境。
5. 代码内默认值：通过注解或常量类定义，作为兜底配置。

多来源叠加时，必须明确覆盖规则。例如 Spring Boot 的加载顺序为：命令行参数 > Java 系统属性 > 环境变量 > 配置文件（profile 特定优先于通用）。若未定义清晰的优先级，同一配置项在不同来源中取值不同，就会产生“配置漂移”——这正是多环境冲突的根源之一。

3.3 配置格式：YAML、JSON、Properties 的对比与选型

配置格式决定了配置项的书写方式与解析复杂度。三种主流格式各有优劣，适用场景不同。

以下为同一组配置在三种格式下的写法对比：

# Properties 格式
server.port=8080
server.ssl.enabled=false
datasource.host=10.0.0.1
datasource.port=3306
datasource.pool.maxActive=20
datasource.pool.initialSize=5

// JSON 格式
{
  "server": {
    "port": 8080,
    "ssl": { "enabled": false }
  },
  "datasource": {
    "host": "10.0.0.1",
    "port": 3306,
    "pool": { "maxActive": 20, "initialSize": 5 }
  }
}

# YAML 格式
server:
  port: 8080
  ssl:
    enabled: false
datasource:
  host: 10.0.0.1
  port: 3306
  pool:
    maxActive: 20
    initialSize: 5

从对比中可以看出：Properties 在层级深时会产生大量重复前缀（如 datasource.pool.maxActive），维护成本高；JSON 结构清晰但缺少注释，不适合需要解释的配置项；YAML 在可读性和结构表达上最均衡，但需注意缩进敏感——一个空格错误就可能导致解析失败或层级错位。

3.4 案例：一个典型的多环境配置冲突场景

某电商团队在开发环境使用 application-dev.yml，测试环境使用 application-test.yml，生产环境使用 application-prod.yml。三个文件均包含 datasource.pool.maxActive 配置项，但取值不同：开发环境为 10，测试环境为 30，生产环境为 80。某次发布时，运维人员将测试环境的配置中心命名空间误指向了生产环境，导致生产实例加载了 maxActive=30 的配置。在业务高峰期，数据库连接池迅速耗尽，引发大量超时。

复盘发现，问题根源并非单一配置值错误，而是配置来源的隔离机制缺失：所有环境共用同一个配置中心集群，仅靠命名空间区分，且没有在应用启动时校验“当前环境”与“配置来源环境”的一致性。修复措施包括：

• 为每个环境建立独立的配置中心命名空间，并设置环境标签（如 env=prod），应用启动时校验标签是否匹配。
• 在配置文件中增加 spring.profiles.active 显式声明当前环境，避免隐式推断。
• 对连接池等关键参数设置合理上限，防止配置值异常时拖垮整个应用。

3.5 误区与复盘：配置格式选择的常见陷阱