在java中读取.properties配置文件，主要通过java.util.properties类实现，常见方式有两种：1. 从文件系统路径读取，适用于外部可修改的配置；2. 从类路径读取，更推荐用于应用内部配置。两者均通过inputstream加载配置，使用getproperty()获取键值。.properties文件因其简单直观，适用于扁平化、少量配置的场景，而json/yaml更适合复杂结构或数据交换。处理配置文件时常见陷阱包括路径问题、硬编码默认值、缺乏错误处理、敏感信息泄露等，最佳实践包括优先从类路径加载、使用try-with-resources、健壮的错误处理、外部化配置、敏感信息加密管理、统一配置入口及提供默认值。在spring boot中，可通过@value、@configurationproperties实现类型安全的配置注入，支持多环境配置及配置中心，极大提升了配置管理的便捷性与灵活性。
在Java中读取.properties配置文件，核心就是利用java.util.Properties这个类。它提供了一套非常直观的API来加载、存储和操作键值对数据，这些数据通常以key=value的形式存储在文本文件中。无论是从文件系统还是从类路径加载，它的基本原理都大同小异：先获取一个输入流，然后交给Properties对象去解析。
解决方案
读取.properties文件主要有两种常见方式，取决于你的配置文件是放在文件系统的某个绝对或相对路径，还是作为资源文件打包在你的JAR包里（即在classpath下）。
1. 从文件系统路径读取：这种方式适用于配置文件独立于应用程序包，可能需要外部修改的情况。你需要提供文件的完整路径。
import java.io.FileInputStream;import java.io.IOException;import java.util.Properties;public class ConfigReaderFromFile { public static void main(String[] args) { Properties prop = new Properties(); String configFilePath = "config.properties"; // 假设config.properties在项目根目录或指定路径 // 尝试从文件系统加载 try (FileInputStream fis = new FileInputStream(configFilePath)) { prop.load(fis); // 加载属性文件 System.out.println("数据库URL: " + prop.getProperty("db.url")); System.out.println("用户名: " + prop.getProperty("db.username")); System.out.println("密码: " + prop.getProperty("db.password")); // 尝试获取一个不存在的属性，并提供默认值 System.out.println("默认端口 (如果未设置): " + prop.getProperty("server.port", "8080")); } catch (IOException ex) { System.err.println("读取配置文件出错: " + ex.getMessage()); // 实际应用中，这里可能需要更复杂的错误处理，比如日志记录或抛出自定义异常 } }}
创建一个名为 config.properties 的文件在项目根目录（或 configFilePath 指定的路径）：
立即学习“Java免费学习笔记（深入）”；
db.url=jdbc:mysql://localhost:3306/mydbdb.username=rootdb.password=mypass
2. 从类路径（Classpath）读取：这是更推荐的方式，特别是当配置文件是应用程序的一部分，并且会随着应用程序一起部署时。它避免了硬编码文件路径的问题，让应用程序更具可移植性。
import java.io.IOException;import java.io.InputStream;import java.util.Properties;public class ConfigReaderFromClasspath { public static void main(String[] args) { Properties prop = new Properties(); String configFileName = "application.properties"; // 假设文件在resources目录下 // 尝试从类路径加载 // 使用当前线程的ClassLoader或当前类的ClassLoader try (InputStream input = ConfigReaderFromClasspath.class.getClassLoader().getResourceAsStream(configFileName)) { if (input == null) { System.err.println("对不起，找不到 '" + configFileName + "' 文件。请确保它在classpath中。"); return; } prop.load(input); System.out.println("应用名称: " + prop.getProperty("app.name")); System.out.println("版本: " + prop.getProperty("app.version")); System.out.println("作者: " + prop.getProperty("app.author", "未知")); // 带默认值 } catch (IOException ex) { System.err.println("读取配置文件出错: " + ex.getMessage()); } }}
在你的Maven或Gradle项目的 src/main/resources 目录下创建 application.properties 文件：
app.name=MyAwesomeAppapp.version=1.0.0
可以看到，无论哪种方式，核心都是Properties类的load()方法，它接收一个InputStream。关键在于如何获取这个InputStream。getProperty(key)用于获取指定键的值，而getProperty(key, defaultValue)则允许你在键不存在时提供一个默认值，这在处理可选配置项时非常有用。
为什么我们还需要.properties文件？它和YAML/JSON有何不同？
嗯，这问题问得好。在JSON和YAML大行其道的今天，很多人可能会觉得.properties文件有点“老派”了。但说实话，它依然有其存在的价值，尤其是在一些特定的场景下。
我个人觉得，.properties文件的最大优点就是简单直接。它就是纯粹的键值对，一眼就能看明白，没有复杂的嵌套结构，也没有各种括号、缩进的语法规则。对于那种扁平化的、少量配置项的场景，比如数据库连接字符串、一些服务端口号、应用名称版本号之类的，它简直是完美。维护起来也极其方便，随便一个文本编辑器就能搞定，甚至不需要特定的插件来高亮语法。对于一些老项目，或者只需要少量配置的工具类应用，它仍然是首选，因为它“轻”。
那和JSON/YAML比起来呢？这就像是拿一辆小轿车和一辆SUV比较。
JSON (JavaScript Object Notation)：
优点： 结构化能力极强，可以表示复杂的嵌套对象和数组。它是一种数据交换格式，所以非常适合API响应、日志记录以及需要复杂数据结构的配置。解析速度快，几乎所有编程语言都有成熟的库支持。缺点： 语法相对.properties更严格，多一个逗号或少一个括号都可能导致解析失败。对于人眼来说，阅读起来可能不如.properties直观，尤其是层级深的时候，满眼的括号和引号有点让人头疼。
YAML (YAML Ain’t Markup Language)：
优点： 强调“人类可读性”，通过缩进来表示层级关系，语法比JSON更简洁（少了大量的括号和引号）。同样能表示复杂的嵌套结构，而且非常适合配置文件的场景，很多现代框架（比如Spring Boot、Kubernetes）都倾向于使用YAML作为默认配置文件格式。缺点： 缩进敏感，一个空格的差异都可能导致解析错误，这在团队协作或手动编辑时容易犯错。虽然比JSON更易读，但对于初学者来说，其结构化方式可能需要一点时间适应。
所以，我的看法是：
如果你需要一个扁平、简单、快速上手的配置文件，并且配置项不多，.properties依然是你的好朋友。如果你需要复杂、嵌套、结构化的配置，或者需要与其他系统进行数据交换，JSON是更合适的选择。如果你希望配置既能表示复杂结构，又兼顾人类可读性，并且愿意接受缩进敏感的规则，那么YAML会是现代项目的优选。
选择哪种，很多时候真的是看项目需求、团队习惯以及个人偏好。我个人在一些简单的Java小工具里，还是会习惯性地用.properties，因为它够用，而且真的省心。
处理配置文件时常见的陷阱与最佳实践是什么？
说起配置文件，我可没少踩坑，也总结了一些血泪教训。这东西看起来简单，但真要用好，还是得讲究点策略。
常见的陷阱：
文件路径问题： 这是最最常见的。比如，我一开始总是习惯用new FileInputStream("config.properties")，然后发现程序在IDE里跑得好好的，打包成JAR一运行就报错“文件找不到”。原因就是FileInputStream默认是相对当前工作目录，而打包后的JAR运行环境可能不是你期望的目录。正确的做法是，如果文件是应用的一部分，应该用ClassLoader.getResourceAsStream()从类路径加载；如果文件是外部的，需要明确指定绝对路径或者通过命令行参数传入路径。硬编码默认值： 有时候图省事，直接在代码里写死一些配置值。结果呢？环境一变，比如从开发环境到测试环境，或者数据库地址变了，就得改代码、重新编译、重新部署。这简直是自找麻烦。缺乏错误处理： 配置文件找不到？属性键不存在？load()方法抛IOException？getProperty()返回null？很多时候，我们写代码时会忽略这些异常情况。结果就是，一旦配置文件有点小问题，程序直接崩溃，用户体验极差，排查起来也费劲。修改运行时配置： 有些人会尝试在程序运行期间修改.properties文件，然后期望程序立即生效。这通常是行不通的，因为Properties对象加载后，它只是内存中的一个副本。如果你真的想实现动态配置，那需要更复杂的机制，比如监听文件变化，或者使用专门的配置中心服务。直接改文件并指望立即生效，往往是徒劳的。敏感信息泄露： 数据库密码、API密钥这些敏感信息直接明文写在.properties文件里，然后把文件提交到版本控制系统？这是个巨大的安全隐患！一旦仓库泄露，后果不堪设想。
最佳实践：
优先从Classpath加载： 对于应用程序内部的配置，始终优先使用ClassLoader.getResourceAsStream()。这能保证你的应用无论部署到哪里，只要配置文件在classpath中，就能被找到。使用try-with-resources： 在处理InputStream时，务必使用try-with-resources语句。这能确保流在不再需要时自动关闭，避免资源泄露。健壮的错误处理：load()方法要捕获IOException，并给出有意义的错误提示或日志。getProperty()方法获取值时，要考虑返回null的情况。可以使用getProperty(key, defaultValue)提供默认值，或者在获取后进行null检查。对于关键配置项，如果缺失，甚至可以直接抛出自定义的配置异常，强制程序中断，避免在后续逻辑中出现更隐蔽的错误。外部化配置： 对于不同环境（开发、测试、生产）需要不同配置的情况，将配置文件放在应用程序外部，通过JVM参数、环境变量或特定目录加载。这样，同一套代码部署到不同环境，只需要修改配置文件即可。敏感信息加密或外部管理：对于数据库密码、API密钥等敏感信息，绝对不能明文存储。可以考虑对这些值进行加密，在程序中解密。更推荐的做法是使用专门的秘密管理服务，比如HashiCorp Vault、AWS Secrets Manager，或者利用云服务商提供的密钥管理服务。在开发环境中，可以通过环境变量注入这些敏感值，而不是写入文件。单一配置入口： 避免在代码库的各个角落散布配置读取逻辑。最好有一个专门的ConfigManager或AppConfig类来统一管理所有配置的加载和访问。这样，当配置逻辑需要修改时，只需要在一个地方进行维护。提供默认值： 对于非强制性的配置项，始终提供合理的默认值。这能让程序在某些配置项缺失时也能正常运行，提高健壮性。
总之，处理配置文件，就是要把“配置”和“代码”解耦，让程序更灵活、更健壮、更安全。
如何在Spring Boot等框架中更优雅地管理配置？
当我们从原生Java跳到像Spring Boot这样的现代框架时，配置管理的体验简直是天壤之别。Spring Boot在配置方面做了大量开箱即用的工作，把.properties（以及YAML）的使用提升到了一个全新的高度，让开发者能以更优雅、更类型安全的方式来管理配置。
在Spring Boot中，你几乎不需要手动去写new Properties().load()那些代码了，框架已经帮你把这事儿给办了。它默认会加载src/main/resources目录下的application.properties或application.yml文件。
1. @Value注解：这是最简单直接的方式，用于注入单个配置属性。
import org.springframework.beans.factory.annotation.Value;import org.springframework.stereotype.Component;@Componentpublic class MyService { @Value("${app.name}") // 从application.properties中读取app.name private String appName; @Value("${server.port:8080}") // 如果server.port不存在，则使用默认值8080 private int serverPort; public void printConfig() { System.out.println("Spring Boot App Name: " + appName); System.out.println("Spring Boot Server Port: " + serverPort); }}
application.properties:
app.name=SpringDemoApp
这种方式非常方便，但如果配置项很多，或者需要注入到不同的类中，就会显得有点分散。
2. @ConfigurationProperties注解：这是我个人最喜欢的方式，它提供了一种类型安全的配置管理方案。你可以把相关的配置项映射到一个Java对象上，让配置像普通Java对象一样被管理。
import org.springframework.boot.context.properties.ConfigurationProperties;import org.springframework.stereotype.Component;@Component@ConfigurationProperties(prefix = "db") // 映射所有以"db."开头的属性public class DatabaseProperties { private String url; private String username; private String password; private int maxPoolSize = 10; // 可以设置默认值 // Getters and Setters (Spring Boot需要它们来注入属性) public String getUrl() { return url; } public void setUrl(String url) { this.url = url; } public String getUsername() { return username; } public void setUsername(String username) { this.username = username; } public String getPassword() { return password; } public void setPassword(String password) { this.password = password; } public int getMaxPoolSize() { return maxPoolSize; } public void setMaxPoolSize(int maxPoolSize) { this.maxPoolSize = maxPoolSize; } @Override public String toString() { return "DatabaseProperties{" + "url='" + url + ''' + ", username='" + username + ''' + ", password='[PROTECTED]'" + // 避免打印敏感信息 ", maxPoolSize=" + maxPoolSize + '}'; }}
application.properties:
db.url=jdbc:mysql://localhost:3306/spring_dbdb.username=springuserdb.password=springpassdb.maxPoolSize=20
然后你就可以在其他组件中直接注入DatabaseProperties对象来使用配置了：
import org.springframework.beans.factory.annotation.Autowired;import org.springframework.stereotype.Service;@Servicepublic class DataService { private final DatabaseProperties dbProps; @Autowired public DataService(DatabaseProperties dbProps) { this.dbProps = dbProps; } public void showDbConfig() { System.out.println("DB Config: " + dbProps); }}
这种方式的优势在于：
类型安全： 编译时就能发现类型不匹配的问题。集中管理： 相关的配置属性都集中在一个类中。IDE支持： IDE通常能提供自动补全和验证。外部化： Spring Boot的外部化配置能力，允许你通过命令行参数、环境变量、Profile特定文件等多种方式覆盖这些属性。
3. 多环境配置：Spring Boot对多环境配置的支持简直是神来之笔。你可以在src/main/resources下创建多个配置文件，例如：
application.properties (通用配置)application-dev.properties (开发环境特定配置)application-test.properties (测试环境特定配置)application-prod.properties (生产环境特定配置)
然后通过spring.profiles.active属性来激活特定的环境配置，例如在命令行运行：java -jar your-app.jar --spring.profiles.active=dev或者在application.properties中设置：spring.profiles.active=dev这样，Spring Boot会自动加载通用配置，并用特定环境的配置覆盖同名属性。
4. 配置中心：对于微服务架构或更复杂的分布式系统，Spring Cloud Config Server是终极解决方案。它提供了一个集中式的外部配置管理服务，应用程序可以从Config Server动态获取配置。这意味着你可以在不重启服务的情况下更新配置，这对于生产环境的热更新至关重要。
总而言之，Spring Boot极大地简化了Java应用中的配置管理。从简单的@Value到类型安全的@ConfigurationProperties，再到强大的多环境支持和配置中心，它提供了一套非常完整且优雅的配置解决方案，让开发者可以专注于业务逻辑，而不是繁琐的配置细节。
以上就是如何用Java读取配置文件 Java读取.properties配置文件技巧的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/127674.html
微信扫一扫 
支付宝扫一扫 
