Java原生读配置易踩路径、编码、资源关闭等坑，应优先用ClassLoader.getResourceAsStream()；Spring Boot中@ConfigurationProperties失效多因注解缺失或YAML格式错误；Profile需在application.properties中早于上下文加载时指定；配置中心选型需权衡运维成本与功能需求。
Java原生配置读取容易踩哪些坑
纯Java项目不用Spring时，Properties类仍是主力，但直接用FileInputStream加载配置文件极易出错：路径不对、编码乱码、资源未关闭、空指针。尤其在JAR包中读取application.properties时，new FileInputStream("config/application.properties")必然失败——它只找当前工作目录，不是类路径。
- 优先用
ClassLoader.getResourceAsStream()加载类路径下的配置，比如getClass().getClassLoader().getResourceAsStream("application.properties") - 显式指定编码，
new Properties().load(new InputStreamReader(in, StandardCharsets.UTF_8))，避免Windows平台默认ISO-8859-1导致中文乱码 - 别手动
close()流——用try-with-resources包裹，否则InputStream泄漏会拖慢应用启动 - 环境变量或JVM参数（如
-Denv=prod）需用System.getProperty("env")读取，和Properties内容是两套体系，不能混为一谈
Spring Boot的@ConfigurationProperties绑定失效常见原因
明明写了@ConfigurationProperties(prefix = "app.db")，字段却一直是null或默认值，大概率是漏了三件事：没加@EnableConfigurationProperties（老版本）、没在配置类上加@Component或没被@Configuration标记、YAML/properties里键名拼错或缩进不合法。
- Spring Boot 2.2+ 默认启用
@ConfigurationProperties扫描，但必须保证配置类在组件扫描路径下，或显式用@EnableConfigurationProperties(MyConfig.class) - YAML中
app:和db:之间必须换行且db:顶格对齐，app: db: url: ...这种写法无效 - 属性名用驼峰（
maxConnection）对应配置项app.db.max-connection，中间用短横线分隔，不是下划线 - 如果绑定List或Map，确保YAML结构正确，例如
app.features: [login, pay]比app.features[0]: login更可靠
Spring Profile切换时配置没生效？检查spring.profiles.active加载时机
application-dev.properties存在，spring.profiles.active=dev也写了，但日志里还是打印default——问题往往出在配置加载顺序上。Spring Boot在创建ApplicationContext前就确定Profile，此时application.properties里的spring.profiles.active才有效；若用-Dspring.profiles.active=dev启动，必须确保JVM参数在命令行最前面，且没被其他配置覆盖。
使用 `gh` CLI 与 GitHub 交互。通过`gh issue`、`gh pr`、`gh run` 和 `gh api` 管理 issue、PR、CI 运行以及高级查询。
- 优先在
application.properties里写spring.profiles.active=dev，而不是依赖环境变量，避免容器或CI脚本干扰 - 多个Profile用逗号分隔：
spring.profiles.active=dev,mysql，不是空格或分号 - 自定义
ConfigurableEnvironment或使用SpringApplication.setAdditionalProfiles()属于高级用法，普通项目慎用，容易绕过自动配置逻辑 - 验证是否生效：启动日志搜
Active profiles，或注入Environment对象调用getActiveProfiles()打印
第三方配置中心（如Nacos、Apollo）与Spring Cloud Config怎么选
单体应用用application.yml足够；微服务规模上来后，硬编码配置到Git或本地文件就扛不住了。Spring Cloud Config适合已有Git运维流程的团队，但需要单独部署Config Server；Nacos/Apollo自带UI、灰度发布、监听回调，接入更快，但引入新中间件意味着多一个运维点。
立即学习“Java免费学习笔记（深入）”；
- Spring Cloud Config + Git：配置变更需提交Git + 触发
POST /actuator/refresh，适合强审计要求场景 - Nacos：用
nacos-config-spring-boot-starter，配置监听靠长轮询，@NacosValue可直接注入，但要注意dataId命名规范（如${spring.application.name}-${spring.profiles.active}.yaml） - Apollo：必须用
apollo-client，配置变更自动刷新Bean，但要求AppId与apollo.meta严格匹配，测试环境常因apollo.meta=http://localhost:8080写错成IP导致连不上 - 无论哪种，都别把敏感配置（密码、密钥）明文放配置中心——应结合KMS或Vault做加密解密层
spring:
cloud:
nacos:
config:
server-addr: 127.0.0.1:8848
data-id: myapp-dev.yaml
group: DEFAULT_GROUP
file-extension: yaml
配置中心不是银弹，动态刷新可能引发线程安全问题，比如@Value注入的String被并发修改——真要热更新，优先走@RefreshScope或监听回调重构逻辑，而不是赌字段原子性。
