Spring Boot 配置加载机制解析：Docker 部署中 `spring.profiles.active` 与 `spring.config.location` 的本质区别

前言

在容器化部署 Spring Boot 应用的日常运维工作中，docker-compose.yml 或 Kubernetes Deployment 中经常会出现类似以下的启动配置：

yaml 复制代码

# 写法 A
entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.config.location=application-prod.yml"]

# 写法 B
entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.profiles.active=prod"]

表面上看，两种写法似乎都在"加载生产环境配置"，但它们的底层机制、文件搜索策略、配置合并逻辑完全不同。大量线上事故的根因正是运维人员混淆了这两者的语义，导致 application.yml 中的基础配置（数据库连接、端口号、日志级别等）在容器启动时"凭空消失"，应用要么启动失败，要么以错误的默认值运行。

一、Spring Boot 配置加载的底层机制

1.1 配置文件的默认搜索路径

Spring Boot 在启动时，会按照固定的优先级顺序从多个位置自动搜索配置文件。以 Spring Boot 2.4+ 为基准，默认搜索路径如下（优先级从高到低）：

text 复制代码

1. file:./config/*/          （工作目录下 config 的子目录）
2. file:./config/            （工作目录下的 config 目录）
3. file:./                   （工作目录根）
4. classpath:/config/        （classpath 下的 config 目录）
5. classpath:/               （classpath 根目录，即 jar 包内部）

在上述每个位置中，Spring Boot 会依次尝试以下文件名：

text 复制代码

application.properties
application.yml
application.yaml

如果激活了某个 Profile（例如 prod），则还会额外搜索：

text 复制代码

application-prod.properties
application-prod.yml
application-prod.yaml

1.2 配置文件的加载优先级与合并规则

Spring Boot 的配置加载遵循"高优先级覆盖低优先级"的原则：

外部文件系统的配置 > classpath 内的配置
Profile 专属配置 > 通用配置（application-prod.yml > application.yml）
命令行参数 > 所有配置文件
环境变量 > 配置文件（在多数情况下）

关键点在于：application.yml 和 application-prod.yml 是合并关系 ，而非替换关系。application-prod.yml 中定义的属性会覆盖 application.yml 中的同名属性，但 application.yml 中未被覆盖的属性依然生效。

1.3 配置源（PropertySource）的层次模型

Spring Boot 内部将所有配置抽象为 PropertySource 对象，按优先级排列在一个有序列表中。启动时，ConfigDataEnvironmentPostProcessor（Spring Boot 2.4+）负责扫描、解析并注册这些配置源。

理解这一点对后文至关重要：spring.config.location 直接干预的是"去哪里找文件"这一步骤，而 spring.profiles.active 干预的是"找到文件后激活哪一组"这一步骤。两者作用在配置加载流水线的不同阶段。

二、`--spring.profiles.active=prod` 解析

2.1 语义

该参数的含义是：告诉 Spring 容器当前运行环境为 prod，请按照标准规则激活对应的 Profile 配置文件。

它不指定任何具体文件路径，仅设置一个逻辑标识。Spring Boot 收到该标识后，会在所有默认搜索路径中查找 application-prod.yml（或 .properties、.yaml）。

2.2 实际加载行为

当使用 --spring.profiles.active=prod 启动时，Spring Boot 的完整加载流程为：

text 复制代码

第一步：在所有默认路径中搜索 application.yml / application.properties
第二步：在所有默认路径中搜索 application-prod.yml / application-prod.properties
第三步：将两者合并，application-prod 中的同名属性覆盖 application 中的
第四步：将合并后的配置注入 Environment

2.3 示例演示

假设 jar 包内部结构如下：

text 复制代码

demo-service.jar
├── BOOT-INF/
│   ├── classes/
│   │   ├── application.yml          ← 基础配置（端口、通用数据源等）
│   │   ├── application-dev.yml      ← 开发环境
│   │   └── application-prod.yml     ← 生产环境
│   └── lib/

启动命令：

bash 复制代码

java -jar demo-service.jar --spring.profiles.active=prod

此时 Spring Boot 会：

从 jar 内部加载 application.yml（获取 server.port、公共配置等）
从 jar 内部加载 application-prod.yml（获取生产数据库地址、Redis 地址等）
两者合并，prod 覆盖同名项

2.4 外部配置文件的自动发现

如果在 Docker 容器中将配置文件挂载到标准位置，例如：

yaml 复制代码

volumes:
  - ./config/application-prod.yml:/app/config/application-prod.yml

并将 WORKDIR 设为 /app，那么 Spring Boot 会自动在 file:./config/ 下发现该文件，无需任何额外参数。这是 profiles.active 方案的一大优势------对文件位置有智能搜索能力。

2.5 多 Profile 激活

可以同时激活多个 Profile：

bash 复制代码

--spring.profiles.active=prod,monitor

此时会加载 application-prod.yml 和 application-monitor.yml，后者的优先级更高。

三、`--spring.config.location` 解析

3.1 语义

该参数的含义是：完全替换 Spring Boot 的默认配置文件搜索路径，仅从你指定的位置加载配置。

注意关键词------"替换"（Replace），而非"追加"。

3.2 实际加载行为

当使用 --spring.config.location=application-prod.yml 启动时：

text 复制代码

第一步：Spring Boot 将默认搜索路径列表清空
第二步：仅在你指定的路径（此处为相对路径 application-prod.yml）中查找配置
第三步：加载找到的文件
第四步：不再搜索任何默认路径中的 application.yml

3.3 核心陷阱：默认配置被丢弃

这是最致命的坑。当你写了：

bash 复制代码

java -jar demo-service.jar --spring.config.location=application-prod.yml

Spring Boot 不会再去加载 jar 包内部的 application.yml。如果你的 application-prod.yml 中只写了数据库连接和 Redis 地址，而端口号、日志配置、MyBatis 扫描路径等都在 application.yml 中定义，那么这些配置将全部丢失。

后果可能是：

应用使用默认端口 8080 而非预期的 9090
日志级别回退到 DEBUG，磁盘被撑爆
某些 Bean 因为缺少配置项而初始化失败，应用直接启动报错
更隐蔽的情况：应用正常启动了，但某些功能因配置缺失而静默失效

3.4 路径解析规则

spring.config.location 中的路径遵循以下规则：

写法	含义
`application-prod.yml`	相对于 JVM 工作目录（`user.dir`），不是相对于 jar 包位置
`./config/application-prod.yml`	同上，相对于工作目录
`/app/application-prod.yml`	绝对路径
`file:/app/application-prod.yml`	显式指定 file 协议（推荐）
`classpath:/config/application-prod.yml`	从 classpath 中查找

在 Docker 中，如果 Dockerfile 中没有设置 WORKDIR，或者 WORKDIR 与配置文件实际位置不一致，相对路径就会找不到文件，抛出 Config data resource 'application-prod.yml' is not available 异常。

3.5 指定多个文件

如果确实需要使用 spring.config.location，必须手动列出所有需要的文件：

bash 复制代码

--spring.config.location=classpath:/application.yml,file:/app/application-prod.yml

多个路径用英文逗号分隔。注意：一旦使用了 spring.config.location，所有配置文件的加载都由你显式控制，Spring Boot 不再做任何自动搜索。

四、`--spring.config.additional-location` 解析

4.1 语义

该参数的含义是：在保留 Spring Boot 所有默认搜索路径的前提下，额外追加一个（或多个）配置文件位置。

关键词------"追加"（Additional）。

4.2 实际加载行为

bash 复制代码

java -jar demo-service.jar --spring.config.additional-location=file:/app/application-prod.yml

此时：

Spring Boot 依然会在所有默认路径中搜索 application.yml、application-prod.yml 等
额外在 /app/ 目录下查找 application-prod.yml
如果两处都有同名文件，additional-location 中的优先级更高，会覆盖默认路径中的

4.3 与 `spring.config.location` 的对比

特性	`spring.config.location`	`spring.config.additional-location`
默认搜索路径	❌ 被完全替换	✅ 保留
`application.yml` 自动加载	❌ 不加载（除非显式列出）	✅ 正常加载
适用场景	完全自定义配置来源	在默认配置基础上叠加外部配置
运维友好度	低（容易遗漏）	高（安全）

4.4 典型使用场景

在 Docker 中，jar 包内已经包含了完整的 application.yml 和 application-prod.yml，但运维希望通过 Volume 挂载一个外部文件来覆盖某些敏感配置（如数据库密码）：

yaml 复制代码

entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.config.additional-location=file:/secrets/db-config.yml"]

这样既保留了 jar 内的完整配置体系，又实现了外部敏感信息的注入。

五、三者的本质区别

维度	`spring.profiles.active=prod`	`spring.config.location=...`	`spring.config.additional-location=...`
本质	设置逻辑环境标识	替换配置文件搜索路径	追加配置文件搜索路径
默认路径搜索	✅ 保留	❌ 完全替换	✅ 保留
`application.yml` 加载	✅ 自动加载	❌ 不加载（需显式指定）	✅ 自动加载
Profile 文件搜索	✅ 自动搜索所有标准路径	❌ 仅在指定路径查找	✅ 自动搜索 + 额外路径
多文件支持	自动（按命名约定）	需手动逗号分隔列出	需手动逗号分隔列出
路径容错	高（多路径搜索）	低（路径错误即失败）	中（默认路径仍有效）
Docker 推荐度	⭐⭐⭐⭐⭐	⭐⭐	⭐⭐⭐⭐

六、Docker 环境下的特殊考量

6.1 工作目录（WORKDIR）的影响

Docker 容器的 WORKDIR 直接决定了 JVM 的 user.dir，进而影响所有相对路径的解析。

dockerfile 复制代码

FROM eclipse-temurin:17-jre-alpine
WORKDIR /app
COPY target/demo-service.jar /app/demo-service.jar
COPY config/application-prod.yml /app/config/application-prod.yml
ENTRYPOINT ["java", "-jar", "demo-service.jar", "--spring.profiles.active=prod"]

此时 file:./config/application-prod.yml 能正确解析为 /app/config/application-prod.yml。但如果 WORKDIR 设为 /，而配置文件在 /app/config/ 下，相对路径就会失效。

6.2 Volume 挂载与配置文件

Kubernetes 或 Docker Compose 中常见做法：

yaml 复制代码

volumes:
  - /host/config/application-prod.yml:/app/config/application-prod.yml

使用 --spring.profiles.active=prod 时，只要挂载路径在 Spring Boot 的默认搜索范围内（./config/、./ 等），就能被自动发现，无需修改启动命令。

使用 --spring.config.location 时，路径必须与挂载点精确匹配，且必须包含所有需要的文件。

6.3 镜像分层与配置外置

最佳实践是将配置文件从镜像中剥离，通过 ConfigMap（K8s）或 Volume（Docker）注入：

yaml 复制代码

# docker-compose.yml
services:
  app:
    image: registry.example.com/demo-service:1.0.0
    environment:
      SPRING_PROFILES_ACTIVE: prod
    volumes:
      - ./external-config:/app/config
    working_dir: /app

这种方式下，镜像内只有 application.yml（通用配置），而 application-prod.yml（环境相关配置）通过挂载注入，实现了配置与代码的完全解耦。

6.4 环境变量注入配置

Spring Boot 支持通过环境变量直接覆盖配置项，无需文件：

yaml 复制代码

environment:
  SPRING_DATASOURCE_URL: jdbc:mysql://prod-db:3306/demo_db
  SPRING_DATASOURCE_USERNAME: admin
  SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
  SERVER_PORT: "9090"

这种方式优先级高于所有配置文件，适合注入敏感信息（结合 Docker Secrets 或 K8s Secrets）。

七、常见错误场景与排查

7.1 错误一：使用 `config.location` 导致基础配置丢失

现象： 应用启动后端口变成默认的 8080，日志级别变成 DEBUG，或者报 Could not resolve placeholder 'xxx' 错误。

原因：

yaml 复制代码

# ❌ 错误写法
entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.config.location=application-prod.yml"]

application-prod.yml 中只写了数据源和 Redis，而 server.port、logging.level、mybatis.mapper-locations 等都在 application.yml 中。使用 config.location 后，application.yml 不再被加载。

修复：

yaml 复制代码

# ✅ 方案一：改用 profiles.active（推荐）
entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.profiles.active=prod"]

# ✅ 方案二：改用 additional-location
entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.config.additional-location=file:/app/application-prod.yml"]

# ✅ 方案三：如果必须用 config.location，列出所有文件
entrypoint: ["java", "-jar", "/app/demo-service.jar", "--spring.config.location=classpath:/application.yml,file:/app/application-prod.yml"]

7.2 错误二：相对路径在容器中解析失败

现象： Config data resource 'application-prod.yml' is not available 或 java.io.FileNotFoundException。

原因： WORKDIR 与配置文件实际位置不一致。例如配置文件在 /app/ 下，但写的是相对路径 application-prod.yml，而 WORKDIR 是 /opt。

修复： 使用绝对路径或 file: 协议前缀：

yaml 复制代码

# ❌ 不可靠
--spring.config.location=application-prod.yml

# ✅ 可靠
--spring.config.location=file:/app/application-prod.yml

7.3 错误三：Profile 文件名不匹配

现象： 激活了 prod Profile，但 application-prod.yml 中的配置没有生效。

排查清单：

文件名是否严格为 application-prod.yml（注意大小写、连字符）
文件是否在默认搜索路径中
是否被 spring.config.location 覆盖了搜索路径
YAML 语法是否有错误（Spring Boot 对 YAML 解析失败有时会静默忽略）
文件编码是否为 UTF-8（BOM 头会导致解析异常）

7.4 错误四：`spring.config.location` 末尾缺少斜杠

现象： 指定了一个目录路径，但其中的配置文件未被加载。

bash 复制代码

# ❌ 缺少末尾斜杠，Spring Boot 将其视为文件名而非目录
--spring.config.location=/app/config

# ✅ 末尾加斜杠，表示这是一个目录
--spring.config.location=/app/config/

当路径以 / 结尾时，Spring Boot 会在该目录下按默认文件名规则搜索；不以 / 结尾时，被视为一个具体文件的路径。

7.5 错误五：多环境配置覆盖顺序混乱

现象： 同时挂载了 application.yml 和 application-prod.yml，但某些值不符合预期。

原因： 外部文件系统的配置优先级高于 classpath 内的配置。如果 jar 内有 application-prod.yml，外部 ./config/ 下也有一个，外部的会完全覆盖内部的（同 Profile 下不做合并，而是高优先级整体替代低优先级的同名文件）。

八、Spring Boot 版本差异

8.1 Spring Boot 2.4 的重大变更

Spring Boot 2.4（2020年11月发布）对配置加载机制进行了重构：

引入 ConfigDataEnvironmentPostProcessor 替代旧的 ConfigFileApplicationListener
引入 spring.config.activate.on-profile 替代 YAML 多文档中的 spring.profiles
引入 spring.config.import 支持从任意位置导入配置
spring.config.location 的行为更加严格：一旦指定，默认路径完全失效

8.2 Spring Boot 2.4+ 的 `spring.config.import`

这是 2.4 引入的新机制，可以在配置文件中声明式地导入其他配置：

yaml 复制代码

# application.yml
spring:
  config:
    import:
      - file:/app/extra-config.yml
      - configtree:/etc/secrets/

这为 Docker/K8s 环境提供了更灵活的配置注入方式，无需修改启动命令。

8.3 Spring Boot 3.x

Spring Boot 3.x（基于 Jakarta EE 9+）在配置加载机制上与 2.4+ 保持一致，未引入破坏性变更。但需要注意：

spring.config.location 和 spring.config.additional-location 的语义不变
对 YAML 解析更加严格（SnakeYAML 2.0），某些在 2.x 中能被容忍的格式错误在 3.x 中会直接报错

8.4 版本兼容建议

Spring Boot 版本	推荐方式	注意事项
1.x	`--spring.profiles.active`	`config.location` 行为与 2.x 略有不同
2.0 ~ 2.3	`--spring.profiles.active`	`config.location` 会替换默认路径
2.4+	`--spring.profiles.active` 或 `spring.config.import`	配置加载重构，行为更严格
3.x	同 2.4+	YAML 解析更严格

九、生产环境最佳实践

9.1 Docker Compose 推荐写法

yaml 复制代码

version: "3.9"

services:
  demo-service:
    image: registry.example.com/demo-service:1.0.0
    container_name: demo-service
    restart: always
    working_dir: /app
    environment:
      # 通过环境变量激活 Profile，比写死在 entrypoint 中更灵活
      SPRING_PROFILES_ACTIVE: prod
      # 敏感信息通过环境变量注入，不落盘
      SPRING_DATASOURCE_PASSWORD: ${DB_PASSWORD}
      SPRING_REDIS_PASSWORD: ${REDIS_PASSWORD}
    volumes:
      # 外部配置覆盖（可选）
      - ./config/application-prod.yml:/app/config/application-prod.yml:ro
      # 日志持久化
      - ./logs:/app/logs
    ports:
      - "9090:9090"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:9090/actuator/health"]
      interval: 30s
      timeout: 10s
      retries: 3
      start_period: 60s
    deploy:
      resources:
        limits:
          memory: 1024M

对应的 Dockerfile：

dockerfile 复制代码

FROM eclipse-temurin:17-jre-alpine

WORKDIR /app

COPY target/demo-service.jar demo-service.jar

# 不设置 ENTRYPOINT，由 docker-compose 或 K8s 控制启动命令
# 如果需要默认启动命令：
ENTRYPOINT ["java", \
  "-XX:+UseG1GC", \
  "-XX:MaxRAMPercentage=75.0", \
  "-Djava.security.egd=file:/dev/./urandom", \
  "-jar", "demo-service.jar"]

9.2 Kubernetes 推荐写法

yaml 复制代码

apiVersion: apps/v1
kind: Deployment
metadata:
  name: demo-service
spec:
  replicas: 2
  selector:
    matchLabels:
      app: demo-service
  template:
    metadata:
      labels:
        app: demo-service
    spec:
      containers:
        - name: app
          image: registry.example.com/demo-service:1.0.0
          env:
            - name: SPRING_PROFILES_ACTIVE
              value: "prod"
            - name: SPRING_DATASOURCE_PASSWORD
              valueFrom:
                secretKeyRef:
                  name: db-secret
                  key: password
          volumeMounts:
            - name: external-config
              mountPath: /app/config
              readOnly: true
          resources:
            requests:
              memory: "512Mi"
              cpu: "500m"
            limits:
              memory: "1024Mi"
              cpu: "1000m"
          readinessProbe:
            httpGet:
              path: /actuator/health/readiness
              port: 9090
            initialDelaySeconds: 30
            periodSeconds: 10
          livenessProbe:
            httpGet:
              path: /actuator/health/liveness
              port: 9090
            initialDelaySeconds: 60
            periodSeconds: 15
      volumes:
        - name: external-config
          configMap:
            name: demo-service-config

9.3 配置文件分层策略

推荐的配置分层架构：

text 复制代码

第一层（jar 内）：application.yml
  → 通用配置：端口、日志格式、MyBatis 配置、公共 Bean 定义

第二层（jar 内或外部挂载）：application-{profile}.yml
  → 环境相关配置：数据源地址、Redis 地址、第三方服务 URL

第三层（外部挂载 / 环境变量 / 配置中心）：
  → 敏感信息：密码、密钥、Token
  → 运行时动态配置：限流阈值、开关

9.4 启动参数调优建议

在 Docker 容器中运行 Java 应用，建议同时配置 JVM 参数：

bash 复制代码

java \
  -XX:+UseG1GC \
  -XX:MaxRAMPercentage=75.0 \
  -XX:InitialRAMPercentage=50.0 \
  -XX:+UseContainerSupport \
  -Djava.security.egd=file:/dev/./urandom \
  -Dfile.encoding=UTF-8 \
  -jar /app/demo-service.jar \
  --spring.profiles.active=prod

-XX:+UseContainerSupport：让 JVM 正确识别容器的 CPU 和内存限制（JDK 8u191+ 默认开启）
-XX:MaxRAMPercentage=75.0：堆内存使用容器内存上限的 75%，避免 OOMKilled
-Djava.security.egd=file:/dev/./urandom：避免容器内熵不足导致启动缓慢

十、调试与验证技巧

10.1 查看实际加载的配置源

在 application.yml 中开启：

yaml 复制代码

logging:
  level:
    org.springframework.boot.context.config: DEBUG

启动时日志会输出所有被加载的配置文件路径及其优先级顺序，例如：

text 复制代码

DEBUG o.s.b.c.c.ConfigDataEnvironment - Loaded config file 'class path resource [application.yml]'
DEBUG o.s.b.c.c.ConfigDataEnvironment - Loaded config file 'file [/app/config/application-prod.yml]' with profile 'prod'

如果某个预期中的文件没有出现在日志中，说明它未被加载。

10.2 使用 Actuator 端点验证

yaml 复制代码

management:
  endpoints:
    web:
      exposure:
        include: env, configprops, health

访问 /actuator/env 可以看到所有 PropertySource 及其优先级；访问 /actuator/configprops 可以看到所有 @ConfigurationProperties 的实际绑定值。

10.3 启动时打印激活的 Profile

Spring Boot 启动日志中会有一行：

text 复制代码

The following 1 profile is active: "prod"

如果没有出现这行，或者显示的 Profile 不是预期值，说明 spring.profiles.active 未正确传入。

10.4 容器内验证

bash 复制代码

# 进入容器
docker exec -it demo-service sh

# 检查配置文件是否存在
ls -la /app/config/
cat /app/config/application-prod.yml

# 检查工作目录
pwd

# 检查环境变量
env | grep SPRING

# 检查 Java 进程的完整启动命令
ps aux | grep java
cat /proc/1/cmdline | tr '\0' ' '

十一、高频面试 / 运维考核问题

Q1：spring.config.location 和 spring.config.additional-location 的核心区别是什么？

A：前者替换默认搜索路径，后者追加搜索路径。使用前者后，application.yml 不会被自动加载；使用后者则不影响默认行为。

Q2：为什么在 Docker 中不推荐使用 spring.config.location？

A：因为它会覆盖默认配置搜索机制，需要手动列出所有配置文件路径，容易遗漏 application.yml，且路径必须与容器内文件系统精确匹配，维护成本高、出错率高。

Q3：spring.profiles.active 可以通过哪些方式设置？优先级如何？

A：

命令行参数：--spring.profiles.active=prod（最高）
环境变量：SPRING_PROFILES_ACTIVE=prod
JVM 系统属性：-Dspring.profiles.active=prod
application.yml 中：spring.profiles.active: prod（最低）

命令行 > 环境变量 > JVM 属性 > 配置文件。

Q4：Spring Boot 2.4 中 spring.config.import 解决了什么问题？

A：它允许在配置文件内部声明式地导入外部配置，无需修改启动命令。支持导入文件、目录、ConfigTree、甚至远程配置中心，是 spring.config.location 的更优雅替代方案。

Q5：如果必须使用 spring.config.location，如何确保 application.yml 不丢失？

A：显式列出所有文件：

bash 复制代码

--spring.config.location=classpath:/application.yml,classpath:/application-prod.yml,file:/external/override.yml

或者改用 spring.config.additional-location。

十二、总结

Spring Boot 的配置加载机制看似简单，实则涉及搜索路径、优先级、Profile 激活、版本差异等多个维度的交叉。在容器化部署场景下，文件系统的隔离性、工作目录的不确定性、Volume 挂载的路径映射等因素进一步放大了配置错误的风险。

核心原则只有一条：

在绝大多数 Docker / K8s 部署场景中，使用 --spring.profiles.active=prod（或环境变量 SPRING_PROFILES_ACTIVE=prod）是最安全、最简洁、最不容易出错的选择。

只有在以下特殊场景才考虑使用 spring.config.location 或 spring.config.additional-location：

配置文件命名不符合 application-{profile} 约定
需要从非标准路径加载配置且无法调整目录结构
需要完全接管配置来源（如配置中心 Agent 已生成最终配置文件）

Spring Boot 配置加载机制解析：Docker 部署中 `spring.profiles.active` 与 `spring.config.location` 的本质区别

前言

一、Spring Boot 配置加载的底层机制

1.1 配置文件的默认搜索路径

1.2 配置文件的加载优先级与合并规则

1.3 配置源（PropertySource）的层次模型

二、--spring.profiles.active=prod 解析

2.1 语义

2.2 实际加载行为

2.3 示例演示

2.4 外部配置文件的自动发现

2.5 多 Profile 激活

三、--spring.config.location 解析

3.1 语义

3.2 实际加载行为

3.3 核心陷阱：默认配置被丢弃

3.4 路径解析规则

3.5 指定多个文件

四、--spring.config.additional-location 解析

4.1 语义

4.2 实际加载行为

4.3 与 spring.config.location 的对比

4.4 典型使用场景

五、三者的本质区别

六、Docker 环境下的特殊考量

6.1 工作目录（WORKDIR）的影响

6.2 Volume 挂载与配置文件

6.3 镜像分层与配置外置

6.4 环境变量注入配置

七、常见错误场景与排查

7.1 错误一：使用 config.location 导致基础配置丢失

7.2 错误二：相对路径在容器中解析失败

7.3 错误三：Profile 文件名不匹配

7.4 错误四：spring.config.location 末尾缺少斜杠

7.5 错误五：多环境配置覆盖顺序混乱

八、Spring Boot 版本差异

8.1 Spring Boot 2.4 的重大变更

8.2 Spring Boot 2.4+ 的 spring.config.import

8.3 Spring Boot 3.x

8.4 版本兼容建议

九、生产环境最佳实践

9.1 Docker Compose 推荐写法

9.2 Kubernetes 推荐写法

9.3 配置文件分层策略

9.4 启动参数调优建议

十、调试与验证技巧

10.1 查看实际加载的配置源

10.2 使用 Actuator 端点验证

10.3 启动时打印激活的 Profile

10.4 容器内验证

十一、高频面试 / 运维考核问题

十二、总结

二、`--spring.profiles.active=prod` 解析

三、`--spring.config.location` 解析

四、`--spring.config.additional-location` 解析

4.3 与 `spring.config.location` 的对比

7.1 错误一：使用 `config.location` 导致基础配置丢失

7.4 错误四：`spring.config.location` 末尾缺少斜杠

8.2 Spring Boot 2.4+ 的 `spring.config.import`