Java配置文件路径的核心结论是：优先使用classpath相对路径，生产环境通过外部参数覆盖，避免硬编码绝对路径。 这样写既能保证本地开发时直接运行，又能让部署到服务器后灵活切换配置,减少改代码的麻烦。
java配置文件路径的三种主流写法
很多初学者拿到一个项目，第一反应是把配置文件放在某个磁盘目录下，然后用绝对路径去读，这个思路本身没错，但放到团队协作或服务器上就很容易出问题，因为每个人的目录结构不同，测试环境和生产环境的路径也不一样，硬编码绝对路径会让项目变得很脆，行业共识是除非有特殊要求,否则不要写死绝对路径。
classpath路径：最省心的选择
把配置文件放在src/main/resources目录下，编译后它会自动进入classpath根目录，读取时直接写文件名即可，比如config.properties，或者带包路径的com/example/config.properties，这种方式的好处在于，打包成jar或war后，文件被封装在内部，程序自己就能找到,不需要关心当前工作目录在哪。
实际操作中，最常用的是ClassPathResource或者getResourceAsStream,以普通Java项目为例：
InputStream in = TestConfig.class.getClassLoader().getResourceAsStream("config.properties");
这样写无论从IDE启动还是命令行运行，都能正确获取，如果是Spring Boot项目，application.properties本身就放在classpath根下，默认就会加载,不用额外指定。
相对路径：依赖启动目录的坑
相对路径是相对于JVM的启动目录而言的，不是相对于某个类文件，很多人在本地IDE里跑没事，因为IDE默认把工作目录设成了项目根目录，但用java -jar启动时，工作目录变成执行命令时所在的目录，相对路径就会失配，比如你写FileReader("config.properties")，启动时不在项目目录下,文件就找不到。
所以相对路径并非完全不可用，但必须明确它的行为受启动位置影响，如果只是临时开发脚本，可以用；若是正式项目,建议直接用classpath或外部路径。
绝对路径：只适合特殊情况
绝对路径在本地测试或固定服务器的特定目录下可以使用，比如/etc/myapp/config.properties，它的优点是直观、好排查，但移植性差，换一台机器就要改代码或配置，更好的做法是把绝对路径作为外部参数传入,后面会详细介绍。
开发环境和生产环境的路径差异怎么处理
开发时你可以在resources下放一个application-dev.properties，用classpath直接读，到了生产环境，配置文件的路径往往需要指向服务器上的固定目录，比如/opt/myapp/config/，这时候如果还是用classpath里的文件，每次改配置都要重新打包,非常麻烦。
使用Spring Boot的profile机制
Spring Boot天然支持多环境配置，你把通用配置写在application.properties，不同环境用application-dev.properties、application-prod.properties分别覆盖,启动时通过参数指定：
java -jar myapp.jar --spring.profiles.active=prod
这样classpath里的路径不变，但内容可以按环境切换，不过对于密码、数据库地址等敏感信息,放到外部文件更安全。
外部配置文件路径覆盖classpath
Spring Boot允许通过spring.config.location指定外部配置文件路径,优先级高于classpath内的文件。
java -jar myapp.jar --spring.config.location=/opt/myapp/config/application.properties
也可以使用环境变量SPRING_CONFIG_LOCATION，这种做法的好处是，运维人员可以直接修改服务器上的配置文件，不需要碰jar包，也不用重新构建，据Spring Boot官方文档说明，外部配置的优先级排在classpath之前,这是行业常识。
对于非Spring项目，你可以自己写一个简单的配置类，启动时先读外部路径，如果找不到再回退到classpath，推荐使用-Dconf.path这类JVM参数传入路径，代码里用System.getProperty("conf.path")获取,这样部署时只需要改启动脚本。
java读取配置文件的实操步骤
很多人搞不清配置文件路径应该怎么写，其实本质是三个问题：文件在哪里、代码怎么定位、运行时怎么覆盖,下面用最常用的方式走一遍。
用getResourceAsStream读取classpath文件
这是最稳妥的方式，假设你要读conf/settings.properties，注意放在resources/conf/下,代码这样写：
Properties props = new Properties();
try (InputStream is = MyClass.class.getClassLoader().getResourceAsStream("conf/settings.properties")) {
props.load(is);
} catch (IOException e) {
// 处理异常
}
getClassLoader()会从classpath根目录开始找，不会受当前工作目录干扰，如果你用的是MyClass.class.getResourceAsStream("/conf/settings.properties")，注意开头的斜杠表示绝对路径，不要写错，业内专家指出，这种方式在绝大多数Java项目里都够用,且代码可维护性高。
运行时动态切换外部配置
生产环境经常需要在不重启进程的情况下更新配置，一种简单做法是启动时读外部文件，但定期检查文件的修改时间，更常见的方案是把路径放在启动参数里，每次重启时加载,具体操作如下：
- 在启动脚本中加上
-Dconf.path=/opt/myapp/config/。 - Java代码里用
System.getProperty("conf.path")拼出完整路径。 - 如果该路径不存在,则回退到classpath资源。
这样既保留了默认配置，又允许外部覆盖，注意Windows和Linux路径分隔符不同，建议用File.separator或Path类。
java配置文件路径常见问题解答
配置文件放在resources下为什么还是找不到？
如果是Maven项目，检查resources目录是否被正确识别为资源目录，默认情况下，src/main/resources会被打进classpath，但如果你在pom.xml里自定义了资源目录，需要确保包含它，另一个常见原因是用了错误的读取方式，比如使用new File("src/main/resources/config.properties")，这行代码在IDE里能跑，但打包后src目录根本不存在,所以实战中必须避免。
为什么生产环境要指定外部路径而不是直接改jar包里的配置文件？
因为修改jar包里的文件容易破坏包完整性，而且每次改配置都要重新打包发布，效率极低，外部配置路径允许运维直接编辑文本文件，改动即时生效，还能通过版本控制管理配置，据统计，较多数量的企业项目会选择将配置文件外置，尤其是涉及数据库密码或第三方API密钥时,这种隔离也更安全。
Spring Boot中如何比较不同配置路径的优先级？
Spring Boot配置加载顺序有明确规则：命令行参数高于外部配置文件，外部配置文件高于classpath内的配置文件。--spring.config.location指定外部目录时，该目录下的文件会覆盖jar内的同名配置，如果同时存在多个位置，按顺序加载，后面覆盖前面,建议你直接运行一条命令测试效果：
java -jar myapp.jar --spring.config.location=classpath:/,file:/opt/myapp/config/
这样classpath和外部路径同时生效，外部文件覆盖默认值,非常适合生产场景。
最后再强调一遍，不管项目大小，配置文件路径的核心思路就是：开发时用classpath，部署时用外部参数，你只需要记住这个原则，遇到具体场景时套用对应的读写方式，就能少踩很多坑，路径问题看似简单，真正出了问题往往很难排查，所以一开始就把方案定清楚,后续能省下不少精力。