将配置文件放到jar包外部，通过启动参数或约定路径动态加载，是生产环境最稳妥的读取方式；若读取jar包内部的配置文件，直接使用getResourceAsStream即可。很多开发者第一次部署Java应用时，都会在“配置文件到底放哪”这个问题上栽跟头，放在jar包里面，改个数据库密码就得重新打包；放在外面，又担心程序找不到，这篇文章会把这几种场景的玩法一次讲透，包括打包时怎么处理、运行时怎么定位、以及容器化部署时怎么挂载配置。
为什么非要从jar包外部读取配置
jar包本质是一个压缩文件，内部的文件对于运行中的Java进程来说是只读的，当你的应用部署在服务器上，如果配置写死在jar包内，意味着每次修改配置都要经历“修改源码→重新编译→打包→上传→重启”这一整套流程,这在实际运维中非常不友好。
行业共识认为，配置与代码分离是部署的基本要求，环境差异是主要驱动因素：开发环境、测试环境、生产环境的数据库地址、日志级别、接口密钥各不相同，如果每次都去改代码，出错概率极高，把配置外置后，同一份jar包可以在不同环境直接运行，只需要搭配不同的配置文件即可，这也就是所谓的“一次构建，多处运行”。
从安全角度看，像数据库密码这类敏感信息，也不应该被提交到代码仓库或者打进镜像里,外部挂载的配置可以单独管理权限。
jar包读取外部配置文件的核心方案对比
实现外部化配置的途径有好几种,选型时主要看你的项目框架和部署方式。
Spring Boot的application.yml外部化
如果你用的是Spring Boot，这个问题已经被框架原生解决了，Spring Boot的配置加载优先级从高到低依次是：命令行参数、JVM系统属性、操作系统环境变量、jar包同目录的config子目录、jar包同目录的配置文件、classpath内部的config包、classpath根目录。
这意味着你什么都不用做，只要在jar包旁边放一个application.yml，它就会自动覆盖jar包内部的同名配置，如果想改加载位置，启动时用--spring.config.location指定：
java -jar app.jar --spring.config.location=/etc/myapp/application.yml
如果需要加载多个不同用途的配置文件，用spring.config.additional-location追加路径。
原生Java读取外部properties
非Spring项目或者简单的工具类，通常使用java.util.Properties手动加载，核心是拿到外部文件的绝对路径，用FileInputStream读取：
Properties props = new Properties();
String path = System.getProperty("config.path");
try (InputStream in = new FileInputStream(path)) {
props.load(in);
}
启动时通过-Dconfig.path=/opt/myapp/config.properties传入路径，这种做法的好处是零依赖，轻量直接,适合老项目改造或者小型工具。
容器环境下的配置挂载
在Docker或Kubernetes环境里，外部配置的“外部”被进一步抽象了，Docker部署时，通过-v将宿主机的配置目录挂载进容器：
docker run -v /host/config:/app/config -e SPRING_PROFILES_ACTIVE=prod myapp:latest
K8s里则通过ConfigMap或者Secret挂载到指定路径，应用侧感知不到文件来自哪里，只需要在配置中指向容器内的挂载路径即可。关键点是jar包内保留一份默认配置作为兜底,防止挂载缺失时应用无法启动。
配置中心
如果微服务数量较多，机器规模较大，业内更推荐引入配置中心，据行业公开信息，主流方案包括Apollo、Nacos和Spring Cloud Config，它们将配置从文件系统提升到了独立服务，支持动态刷新，修改配置后无需重启应用，适合中大型团队，对于单机部署或者小项目来说，引入配置中心的运维成本偏高,反而得不偿失。
读取jar包内部配置文件的正确姿势
内部读取的场景通常出现在工具类或者需要读取classpath下的模板资源时，这里有一个高频坑：不能使用new File()去读取jar包内的资源，因为jar包内的文件并不是操作系统层面的真实文件,正确做法是使用classloader：
InputStream in = MyClass.class.getResourceAsStream("/config/template.json");
如果使用Spring框架，也可以用ClassPathResource：
Resource resource = new ClassPathResource("template.json");
InputStream in = resource.getInputStream();
这里有个细节需要区分：classpath下的路径不能用开头，而Class.getResourceAsStream的路径以开头表示从classpath根目录查找，很多新手在这里路径写错,导致运行时找不到文件。
不同部署场景的实操步骤
传统服务器部署
在Linux服务器上，建议将配置文件统一放到/etc/appname/目录下，启动脚本中显式指定路径,目录结构如下：
/opt/myapp/
├── app.jar
└── config/
└── application-prod.yml启动命令：
java -jar /opt/myapp/app.jar --spring.profiles.active=prod --spring.config.location=/opt/myapp/config/
这样做的好处是应用目录干净，配置和程序分离,备份和迁移时只需要拷贝配置目录即可。
Windows环境运行
Windows下遇到最多的问题是路径分隔符，外部配置路径建议统一使用正斜杠，Java在Windows下也能正确解析，如果路径中包含空格，在启动脚本中务必加引号,否则参数会被截断。
java -jar "D:\My Apps\app.jar" --spring.config.location="D:\My Apps\config\"
Docker部署时配置文件修改不了怎么办
容器部署后，很多人发现进入容器手动改配置文件，重启后修改就丢失了，这是因为容器是临时的，正确做法是在宿主机维护配置，通过挂载目录或卷的方式传入，推荐使用docker compose管理：
services:
app:
image: myapp:1.0
volumes:
- ./config:/app/config
environment:
- SPRING_PROFILES_ACTIVE=prod
常见问题排查与解决
文件明明存在却读取不到？ 首先检查当前工作目录，jar包启动时，new File("config.properties")的相对路径是相对于进程的启动目录，而不是jar包所在目录，这属于初学者最容易踩的坑，解决方法：在启动脚本中先cd到jar包所在目录再执行,或者代码中基于绝对路径定位。
读取到的配置还是旧的？ 检查是否存在多个同名配置文件，classpath内部文件、jar包外部文件、启动参数指定的文件，三者同时存在时优先级不同，使用--spring.config.location时，它会替换默认的classpath配置，而不是追加；如果只想追加，使用
additional-location。
配置文件中文乱码？ 这通常是编码问题。Properties.load方法默认使用ISO-8859-1编码读取，中文需要转成Unicode转义符，或者改用Reader方式读取并指定UTF-8：
props.load(new InputStreamReader(in, StandardCharsets.UTF_8));
jar包读取配置文件时提示NullPointerException？ 通常是路径写错了，导致getResourceAsStream返回null,可以先打印出当前classpath的实际结构来定位问题：
System.out.println(System.getProperty("java.class.path"));
一些关于配置管理的实用建议
配置外置后，随之而来的是配置的版本管理和一致性维护，建议将所有外部配置纳入Git仓库单独管理，按环境分目录存放，禁止把生产环境的真实密码提交到仓库,可以使用环境变量引用或者脱敏工具处理。
日志路径也建议一并外置，很多应用默认将日志写在当前目录，如果启动目录不对，日志会散落各处，在配置文件中指定绝对日志路径，配合logback或log4j2的外置配置文件,运维排查问题时会轻松很多。
配置读取路径常见问题
问：jar包读取配置时，配置文件放在哪个目录最合适？
放在与jar包同级的config子目录中是最常规的做法，Spring Boot会自动识别，对于系统级应用，使用/etc/项目名/更加规范；对于用户级应用，可以放在用户主目录下的隐藏目录，例如~/.appname/。
问：Spring Boot项目打包后，为什么application.yml的修改不生效？
如果jar包内和jar包外都有application.yml，外部的优先级更高，但有时因为缓存或者启动脚本中的参数覆盖导致不生效，建议在启动命令中明确指定--spring.config.location指向外部文件绝对路径，同时检查是否在application.yml中设置了spring.config.import引入其他配置，这会导致额外的加载逻辑，确保修改的是最终生效的那一份配置，通过actuator的env端点可以查看当前生效的属性来源。