Java 使用 Properties 加载 .properties 文件方法

本文深入解析了Java中使用Properties加载.properties配置文件的常见陷阱与最佳实践，重点揭示了路径错误导致load()失效的根本原因，并强调必须通过类加载器getResourceAsStream()安全获取资源流且务必判空；针对中文乱码问题，指出默认ISO-8859-1编码限制，推荐使用UTF-8 Reader显式解码；在Spring Boot环境下明确反对手动加载，倡导优先采用@ConfigurationProperties等原生机制以享受自动绑定、多环境支持与类型安全；同时提醒Properties并非线程安全配置容器，启动后应封装为不可变对象，避免将其误用为通用键值存储——帮你避开从本地调试到JAR部署、从字符编码到架构演进的全链路坑点。

Properties.load() 为什么读不到文件或抛出 IOException

根本原因通常是路径没对，或者资源没被正确加载。Java 的 Properties.load() 接收的是 InputStream，不是文件路径字符串 —— 直接传 new FileInputStream("config.properties") 在 IDE 里可能跑得通，但打成 JAR 后就找不到文件，因为此时文件已不在文件系统中，而在 classpath 的 jar 包内。

正确做法是用类加载器获取资源流：

Properties props = new Properties();
try (InputStream is = MyClass.class.getClassLoader().getResourceAsStream("config.properties")) {
    if (is == null) {
        throw new IllegalArgumentException("config.properties not found in classpath");
    }
    props.load(is);
}

• 确保 config.properties 放在 src/main/resources/（Maven 项目）或等效的 classpath 根目录下
• 不要写路径前缀 /config.properties：带斜杠会从 classpath 根开始找；不带斜杠则相对当前类所在包查找（容易出错，建议统一用根路径）
• 注意 getResourceAsStream() 返回 null 时不抛异常，必须手动判空，否则 props.load(null) 会触发 NullPointerException

中文乱码问题：load() 和 loadFromXML() 的编码差异

默认 Properties.load() 按 ISO-8859-1 解码，遇到中文会显示为 \u4f60\u597d 这类 Unicode 转义 —— 这不是错误，是规范行为。但直接写中文到 .properties 文件里，又没做转义，就会乱码。

解决方式分两种场景：

• 若能控制文件生成：用 native2ascii 工具（JDK 自带）转义中文，或用 IDE 的 “Save as UTF-8 with Unicode escape” 功能
• 若需直接读 UTF-8 原生内容（更常见）：改用 Properties.load(Reader)，配合 InputStreamReader 指定编码：

try (InputStream is = MyClass.class.getClassLoader().getResourceAsStream("config.properties");
     Reader reader = new InputStreamReader(is, StandardCharsets.UTF_8)) {
    props.load(reader);
}

注意：loadFromXML() 默认支持 UTF-8，但要求文件是 XML 格式（），和传统 .properties 不兼容。

Spring Boot 里还该手写 Properties.load() 吗

不该。Spring Boot 的 @Value、@ConfigurationProperties 和 Environment 已经封装了自动加载、类型转换、占位符解析（如 ${db.port:3306}）、多环境配置（application-dev.properties）等能力，手写 Properties 反而绕过这些机制，还丢失 profile 激活、Relaxed Binding 等特性。

仅在以下情况才考虑手动加载：

• 需要动态加载外部（非 classpath）的 .properties 文件，比如用户指定路径的配置
• 集成遗留模块，对方强依赖 Properties 实例
• 做配置热刷新时，需绕过 Spring 的缓存机制（但应优先考虑 @RefreshScope）

即便如此，也建议用 ResourceLoader 替代硬编码的 ClassLoader，便于测试和替换：

Resource resource = resourceLoader.getResource("classpath:custom.properties");
try (InputStream is = resource.getInputStream()) {
    props.load(is);
}

Properties 实例是否线程安全

不安全。Properties 继承自 Hashtable，虽然部分方法加了 synchronized，但复合操作（如先 containsKey() 再 getProperty()）仍存在竞态。更严重的是，Java 9+ 中 Properties 的底层存储已改为非同步的 HashMap，连单个方法都不再保证同步。

实际使用中要注意：

• 配置加载通常在启动阶段完成，之后只读 —— 此时用 Collections.unmodifiableProperties(props) 封装一次最稳妥
• 若需运行时修改（极少见），应自行加锁，或改用 ConcurrentHashMap + 手动解析逻辑
• 别把 Properties 当作通用键值容器反复 put/get；它没有泛型、无类型检查，易引发 ClassCastException

真正容易被忽略的是：很多人把 Properties 当作“轻量级配置工具”直接注入 service 层，却没意识到它既不支持嵌套结构，也不支持类型推导 —— 一旦配置项变多或需要校验，维护成本会陡增。

到这里，我们也就讲完了《Java 使用 Properties 加载 .properties 文件方法》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！