Java读取properties文件应避免ClassLoader.getResourceAsStream("/")路径错误，用上下文类加载器并判空；Spring Boot配置优先级需通过debug日志和getPropertySources()分析；@ConfigurationProperties绑定失败主因是缺少@Component/@EnableConfigurationProperties、命名不匹配或Lombok无@Setter；热更新推荐@RefreshScope或AtomicReference+WatchService，而非已移除的ReloadingPropertySource。
Java 读取 properties 文件最常用却最容易出错的方式
直接用 ClassLoader.getResourceAsStream() 加载 application.properties 是多数人的第一选择，但路径错误、类路径污染、IDE 缓存干扰会让它在测试时正常、打包后失效。
- 确保文件放在
src/main/resources/下，否则 Maven 不会将其复制到target/classes/ - 不要写成
getResourceAsStream("/application.properties")—— 开头的/会让 JVM 从 classpath 根开始找，而实际资源已在根目录，多加斜杠反而找不到 - 用
Thread.currentThread().getContextClassLoader().getResourceAsStream("application.properties")比getClass().getClassLoader()更健壮，尤其在 Spring 或 OSGi 环境下 - 记得判空：如果返回
null，说明资源未加载成功，别直接传给Properties.load()，否则抛NullPointerException
Spring Boot 外部配置优先级混乱时该怎么 debug
当 application.yml、application.properties、JVM 参数（-Dserver.port=8081）、环境变量（SERVER_PORT=8082）同时存在，最终生效值常让人困惑。
- 启动时加参数
--debug或设置logging.level.org.springframework.boot.context.config=DEBUG，Spring 会打印所有已加载的配置源及顺序 - 调用
ConfigurableEnvironment.getProperty("server.port")只能拿到最终结果，看不出来源；用environment.getPropertySources()遍历才能看到每个 source 的 name 和 origin -
spring.config.location（如file:/etc/myapp/config/）优先级高于 classpath，但必须是绝对路径且结尾带/，否则被当成文件名处理
自定义配置类 + @ConfigurationProperties 绑定失败的三个典型原因
明明写了 @ConfigurationProperties(prefix = "myapp.db")，字段却一直是默认值或 null，通常不是注解没生效，而是绑定环节断了。
- 类上漏了
@Component或没被@EnableConfigurationProperties(MyAppDbConfig.class)显式启用 - 配置项写成了
myapp.db-url=jdbc:h2:mem:test，但 Java 字段叫url——-在 properties 中合法，但默认不映射到驼峰字段，需开启spring.main.allow-circular-references=true？不对，这是另一回事；正确解法是字段命名用dbUrl，或加@ConfigurationPropertiesBinding自定义转换器 - 配置类用了
lombok.Data，但没加@Setter（Lombok 1.18.20+ 默认不生成 setter），导致 Binder 无法设值 —— 最简验证：手动加个public void setUrl(String url) { this.url = url; }，看是否恢复
运行时热更新配置：为什么 ReloadingPropertySource 不是银弹
想让配置改完自动生效？别急着抄 ReloadingPropertySource 示例。Spring Boot 2.4+ 已移除该类，且即使低版本可用，也只监听文件变化，不触发 Bean 重建或方法重执行。
立即学习“Java免费学习笔记（深入）”；
-
@RefreshScope是目前最稳妥的方案，但仅对 Spring 容器管理的 Bean 生效，且首次访问才初始化，不适合静态工具类 - 若用
ApplicationContext.publishEvent(new EnvironmentChangeEvent(...))手动触发刷新，需确保所有监听EnvironmentChangeEvent的组件都实现了响应逻辑 —— 大部分第三方库并不支持 - 真正需要热更新的场景（如限流阈值、开关），建议绕过 Spring 配置体系，用
AtomicReference+ 文件 WatchService 自行监听并更新内存值，更可控
Path configPath = Paths.get("/etc/myapp/config.properties");
WatchService watcher = FileSystems.getDefault().newWatchService();
configPath.getParent().register(watcher, StandardWatchEventKinds.ENTRY_MODIFY);
// 后续轮询事件并 reload Properties
配置热更新的边界很窄：它解决不了依赖注入链中深层 Bean 的状态同步，也解决不了静态 final 字段的重赋值。真要动态，得从设计上接受“配置即服务”的思路，而不是把配置当全局变量塞进每个角落。 
