不能直接硬编码环境判断，因为所有profile配置文件若一并打包进jar，会导致非目标环境的敏感信息（如数据库密码、密钥）随包发布，违反最小权限原则且易被反编译泄露；git分支隔离配置文件可确保每次构建仅含目标环境配置，结合ci校验与.dockerignore兜底，实现安全、纯净的多环境交付。

为什么不能直接在代码里硬编码环境判断

Spring Boot 的 spring.profiles.active 确实能切换 application-dev.yml 或 application-prod.yml，但前提是这些文件得真实存在于构建产物中。如果所有环境配置都塞进同一份 jar 包，哪怕只用其中一个 profile，其他环境的敏感字段（比如数据库密码、第三方密钥）依然会随包一起发布——这违反最小权限原则，也容易被反编译泄露。

Git 分支决定哪些 YAML 文件参与构建

核心思路是：让不同 Git 分支只保留对应环境的配置文件，其余全部从工作树中移除。CI 流水线基于分支拉取代码后，application.yml + 对应的 application-{profile}.yml 就是唯一存在的配置组合。

• develop 分支只保留 application.yml 和 application-dev.yml，删掉 application-test.yml、application-prod.yml
• release/uat 分支只留 application.yml 和 application-uat.yml
• main 分支只含 application.yml 和 application-prod.yml

这样每次构建出来的 jar 包，天然就只带目标环境的配置，无需额外过滤或替换。

合并时如何避免配置文件冲突

直接 merge 分支会导致 application-test.yml 和 application-prod.yml 在同一提交里共存，破坏“单环境纯净”原则。必须用保护性策略：

Digital Twin Discharge Drafter

用于撰写患者出院小结、制定个性化出院指导、模拟出院后结局、降低再入院率

下载

• 在 Git 仓库设置分支保护规则：禁止向 main、release/* 直接 push，所有变更必须走 Merge Request
• Merge Request 提交前，CI 脚本自动检查：当前分支是否只存在且仅存在一个非 application.yml 的 profile 文件（如 application-prod.yml）
• 拒绝包含多个 application-*.yml 的 PR，强制开发者先清理冗余配置文件再提交

Docker 构建时如何确保只打包当前分支的配置

别依赖本地工作树状态。CI 中执行 docker build 前，必须用干净克隆：

git clone --branch $CI_COMMIT_REF_NAME --depth 1 https://your-repo.git /tmp/app
cd /tmp/app
docker build -t myapp:$CI_COMMIT_REF_NAME .

同时，在 .dockerignore 中明确排除可能残留的配置：

• **/application-test.yml
• **/application-dev.yml
• secrets/**

即使某次提交意外混入了不该有的配置文件，.dockerignore 也能兜底拦截。

真正难的是团队对分支生命周期的共识——不是技术做不到，而是有人在 develop 分支上偷偷加了 application-prod.yml 用于本地调试，结果一不小心合进了 main。这种事不会报错，但会让生产环境配置暴露在测试镜像里。