静态代码块适合类加载时一次性读取固定配置，但不支持热更新且易因路径错误或异常导致初始化失败；应通过类加载器从classpath加载资源，严格校验流、编码和枚举绑定，并避免在热部署场景中依赖其管理运行时配置。
静态代码块适合在类加载阶段一次性读取配置，但不是万能方案——它只执行一次、不支持热更新、对路径和异常极其敏感。用对了能消除硬编码、提升语义清晰度；用错了会导致类初始化失败、配置静默丢失、启动卡死。
优先走类路径加载，别碰绝对路径
打包后用 FileInputStream("config.properties") 必然失败，因为文件已不在文件系统根目录。正确做法是通过类加载器从 classpath 加载：
- 推荐写法：
MyClass.class.getClassLoader().getResourceAsStream("application.properties")，路径不带前导斜杠，表示从 classpath 根开始找 - 同包资源可用：
MyConfig.class.getResourceAsStream("app.conf") - classpath 根下资源（如
resources/static/logo.png）写成：MyConfig.class.getResourceAsStream("/static/logo.png") - 务必检查流是否为 null：没找到资源时方法返回 null 而非抛异常，需主动判断并给出明确提示或 fallback
流操作要严谨，避免初始化中断
静态块里任何未捕获的异常都会包装成 ExceptionInInitializerError，导致整个类不可用。安全读取的关键细节：
- 用 try-with-resources 自动关闭流，防止资源泄漏
- 含中文的 properties 文件必须指定编码：
properties.load(new InputStreamReader(is, "UTF-8"))，Java 8+ 默认用 ISO-8859-1 解码 - 所有赋值逻辑（如
dbUrl = props.getProperty("db.url")）必须放在 try 块内，避免部分字段未初始化就抛异常 - 异常日志要带上下文，例如“Failed to load config.properties: file not found or unreadable”，不能只调
e.printStackTrace()
用枚举绑定配置值，告别魔法数字
静态块不只是把字符串转成变量，更是建立配置与业务语义的桥梁：
- 定义枚举时携带业务含义：
ORDER_PENDING(1), ORDER_SHIPPED(2) - 读到
order.status.pending=1后，不直接赋 int 值，而是验证OrderStatus.PENDING是否存在 - 在枚举中补充
public static OrderStatus fromCode(int code)方法，遍历values()匹配，找不到则抛IllegalArgumentException - 后续所有数据库查询、接口返回、条件分支都使用枚举引用，编译期可校验、IDE 可提示、重构可联动
热部署场景下，静态块不会重执行
Spring Boot DevTools 或 Tomcat 热重启时，新类由新类加载器加载，静态变量是全新且为空的——旧值留在老加载器里，无法自动同步：
- 改完 properties 文件再点 “Restart” 并不会刷新 static 字段
- 开发期建议用
@RefreshScope+@ConfigurationProperties配合/actuator/refresh - 生产环境应放弃静态块托管运行时配置，改用 Spring 的配置绑定机制，或监听文件变更后主动 reload
- 若坚持用静态块，仅限加载启动即固定、后续绝不变更的基础参数，比如加密盐值、默认超时毫秒数
不复杂但容易忽略：静态块是初始化的“快车道”，不是配置管理的“终点站”。守住边界，才能既轻量又可靠。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
