Spring Boot 容器化时应严格分离内部配置（application.*）与外部挂载配置，前者由 Spring 自动加载，后者由应用代码主动读取校验；通过环境变量指定路径、bind mount 精确挂载单文件、CommandLineRunner 阶段校验加载，实现职责分层与安全可控。
Spring Boot 容器化时，把内部配置（application.properties 或 application.yml）和外部挂载的配置文件（如密钥、第三方参数等）严格分离，核心在于“职责分层”和“加载时机解耦”。不是简单地把所有配置都扔进 config/ 目录，而是让 Spring Boot 原生机制管好自身配置，再由应用代码主动加载外部文件——两者互不干扰、各自生效。
明确配置边界：哪些归 Spring Boot 管，哪些归外部挂载
Spring Boot 自动加载的配置路径（如 classpath:/、file:./config/、file:./）只用于 application.* 及其 profile 变体（application-dev.yml）。其他非标准配置文件（比如 thirdparty-secrets.properties、encryption-config.json）不应混入其中，否则会污染环境变量解析逻辑，也违背“一个配置源一种用途”原则。
- 内部配置：仅含服务端口、数据库连接池参数、日志级别、Feign 超时等与 Spring Boot 生命周期强绑定的设置；
- 外部挂载配置：专用于第三方 SDK 初始化、加密模块密钥、中间件连接串等，文件名和路径由应用代码显式指定，不参与 Spring 的 PropertySource 自动发现。
用环境变量控制外部文件路径，而非硬编码容器内路径
在 Docker 启动命令中，通过 -e OTHER_CONFIG_PATH=/etc/app/secrets.properties 传入路径，而不是写死在代码里。Spring Boot 应用启动时用 @Value("${other.config.path:/dev/null}") 获取该值，并在校验后读取内容。这样即使挂载路径变更（比如从 /etc/app/ 改为 /mnt/conf/），只需改环境变量，无需重建镜像或修改代码。
- 镜像内保留默认 fallback 路径（如
/dev/null），确保无挂载时也能启动（只是跳过加载）； - 容器运行时用
-v /host/secrets.properties:/etc/app/secrets.properties:ro挂载，权限设为只读，防误写； - 避免使用相对路径（如
./secrets.properties），因工作目录可能随 ENTRYPOINT 变化而不可靠。
在启动阶段主动加载并校验，不依赖 @ConfigurationProperties 自动绑定
外部配置文件不走 Spring 的 @ConfigurationProperties 绑定流程，而是由 CommandLineRunner 或 ApplicationRunner 在主上下文刷新前完成加载。这样能提前捕获文件缺失、格式错误、权限不足等问题，防止服务启动后因配置异常导致运行时失败。
立即学习“Java免费学习笔记（深入）”；
- 用
Files.isReadable(Paths.get(path))判断文件可读性； - 用
new Properties().load(inputStream)加载 .properties，或 Jackson 解析 JSON/YAML； - 加载结果存入静态工具类或 Spring 的
Environment中自定义属性源（ConfigurableEnvironment#getPropertySources().addLast(...)），供后续组件调用。
挂载方式选 bind mount，不用 volume 管理敏感配置
对于密钥、证书等敏感外部配置，必须用 -v（bind mount）挂载宿主机上的具体文件，而不是 --mount type=volume。因为 volume 是 Docker 管理的抽象存储，内容不可见、不可审计，且无法保证单个文件级更新——而 bind mount 能清晰看到来源、便于权限管控和 CI/CD 流水线注入。
- 生产环境建议将挂载目录设为
/etc/app/，符合 Linux FHS 规范，也方便 SELinux/AppArmor 策略配置； - 不要挂载整个目录（如
-v /host/config:/etc/app），应精确到单个文件，避免意外覆盖或暴露多余内容； - 配合
docker-compose.yml使用时，在environment和volumes区块分别声明变量与挂载，结构更清晰。
