静态代码块适合在类加载时一次性初始化全局配置，应使用ClassLoader读取classpath资源、try-with-resources关闭流、捕获异常并记录日志，配置封装为static final不可变对象，避免耗时操作，支持多源fallback，但测试不友好，框架中优先用@ConfigurationProperties。
静态代码块在 Java 中可用于类加载时执行一次性的初始化操作，适合实现全局配置的预读取——即在应用启动、任何实例创建前，将配置加载进内存并供后续使用。
利用静态块读取配置文件
静态代码块会在类首次被加载（如首次访问该类的静态成员或创建实例）时执行，且仅执行一次。可在此处读取 properties 文件、YAML 或 JSON 配置，并存入 static 字段中。
- 确保配置路径正确，推荐使用 ClassLoader.getResourceAsStream() 加载 classpath 下资源，避免硬编码路径
- 用 try-with-resources 确保流及时关闭，防止资源泄漏
- 捕获 IOException 和 IllegalArgumentException，建议记录日志而非抛出异常，避免因配置缺失导致类加载失败
配合 static final 实现不可变全局配置
读取完成后，应将配置封装为不可变对象（如 Map<String, String> 或自定义 Config 类），并用 static final 修饰，保证线程安全与一致性。
- 避免直接暴露可变集合（如 new HashMap()），改用 Collections.unmodifiableMap() 包装
- 若配置含敏感字段（如密码），注意不要在日志中打印原始内容
- 不建议在静态块中做耗时操作（如远程 HTTP 请求），否则会阻塞类加载，影响启动速度
处理多配置源与 fallback 逻辑
实际项目中常需支持多种配置来源（如系统属性 > 环境变量 > 默认配置）。静态块内可按优先级顺序尝试读取：
立即学习“Java免费学习笔记（深入）”；
- 先检查 System.getProperty() 或 System.getenv() 是否已设置关键参数
- 再尝试加载外部配置文件（如 /etc/myapp/config.properties）
- 最后回退到 classpath 内置的 default.properties
- 所有读取结果统一合并到最终配置对象中，覆盖规则需明确（例如后加载的 key 覆盖先加载的）
注意类加载时机与测试友好性
静态块执行依赖 JVM 类加载机制，这在单元测试中可能带来问题：一旦类被加载，静态块只运行一次，无法重置。
- 测试时可通过 restart JVM（如使用 @TestInstance(Lifecycle.PER_CLASS) + 自定义 ClassLoader）隔离状态，但较重
- 更推荐将配置加载逻辑提取为独立方法（如 ConfigLoader.load()），静态字段仅作缓存入口，便于 mock 或重载
- Spring 等框架环境下，优先使用 @ConfigurationProperties 或 @Value，静态块更适合无框架或基础工具类场景
