应避免将application.properties或logback-spring.xml打包进jar包，生产环境必须程序与配置分离；推荐用--spring.config.additional-location=file:/etc/myapp/config/,classpath:/config/挂载外部配置，确保启动时生效且兜底安全。
Java应用启动时如何避免把配置文件打进jar包
直接把application.properties或logback-spring.xml打包进jar，会导致每次改配置都得重编译、重部署，线上出问题时根本来不及响应。关键不是“能不能”，而是“该不该”——生产环境必须把程序逻辑和配置分离。
- Spring Boot默认会按顺序加载配置：classpath:/config/ > classpath:/ >
file:./config/>file:./ - 用
--spring.config.location显式指定外部路径最可靠，比如：java -jar app.jar --spring.config.location=file:/etc/myapp/config/ - 不要依赖
spring.config.name去猜文件名；固定用application.yml或application.properties，否则容易漏加载 - 如果用
Config Server或Nacos，本地bootstrap.yml里只留服务地址，其余全走远程拉取
Docker容器中映射配置文件的常见错误
很多人写Dockerfile时用COPY把配置一起打进去，看似简单，实则破坏了“一次构建、多环境部署”的原则。真正安全的做法是运行时挂载，而不是构建时固化。
- 宿主机目录权限不对会导致Java进程读不到配置：确保
/etc/myapp/config/对容器内运行用户（如1001）可读，别只给root - 用
docker run -v /host/config:/app/config:ro，末尾:ro很重要，防止应用误写配置引发状态污染 - 如果配置含敏感信息（如数据库密码），优先用
docker secret（Swarm）或Kubernetes Secret，而非明文挂载文件 - 注意Windows宿主机路径格式：用
//c/Users/me/config而非C:\Users\me\config，否则Docker Desktop会静默失败
Linux系统部署时如何让不同环境共用同一套jar包
一个jar包在测试、预发、生产三套环境跑，靠的是启动参数和外部配置隔离，不是靠打三个不同jar。这要求从部署脚本开始就杜绝“复制粘贴式配置”。
- 用
systemd管理服务时，在EnvironmentFile=里加载/etc/sysconfig/myapp-prod这类环境变量文件，里面定义JAVA_OPTS和SPRING_PROFILES_ACTIVE - 配置文件路径统一用绝对路径，避免相对路径在
cd切换工作目录后失效；Java进程启动前cd /opt/myapp再执行java -jar是高危操作 - 日志路径也必须外置：
-Dlogging.config=file:/etc/myapp/logback.xml，否则logback-spring.xml里的${LOG_PATH}变量可能解析成容器内部临时路径 - 检查
java -jar命令是否带-Duser.dir，这个JVM参数会覆盖工作目录，干扰file:前缀的配置加载逻辑
为什么spring.config.additional-location比location更稳妥
--spring.config.location会完全替换默认加载路径，一旦写错（比如漏掉classpath:/），连application.properties都加载不到，应用直接启动失败。而additional-location是追加，兜底更牢。
- 推荐组合写法：
java -jar app.jar --spring.config.additional-location=file:/etc/myapp/config/,classpath:/config/ - 这样既保证外部配置优先，又保留classpath下默认配置作为 fallback
- Spring Boot 2.4+之后
location行为有变更，若项目还没升级，务必查清当前版本文档，别照抄新版本示例 - 验证是否生效：启动时加
--debug，看日志里ConfigDataLocationResolvers是否列出你指定的路径
curl http://localhost:8080/actuator/env | grep myapp确认配置已生效，等于没分离。 
