静态代码块初始化集合极危险：因JVM要求初始化“原子成功”，任何异常（如文件不存在、解析失败、循环依赖）均触发ExceptionInInitializerError，致类永久不可用；应改用懒加载、Set.of()安全构造或外部化配置。
静态代码块里初始化集合，看似省事，实则埋雷——一旦出错，类直接“胎死腹中”，后续任何引用都抛 ExceptionInInitializerError，甚至伪装成 NoClassDefFoundError，让人误以为是类路径问题。
为什么集合“写死”在 static 块里特别危险
集合初始化常伴随高风险操作：读配置、解析 JSON、查数据库、调用工具方法。这些动作在类加载阶段执行，而 JVM 对初始化要求“原子成功”——中间哪怕抛一个 NumberFormatException 或 IOException，整个类立刻进入“错误状态”，永不可恢复。
- 例如：
static List<string> ROLES = Files.readAllLines(Paths.get("roles.txt"));</string>—— 文件不存在？权限不足？编码异常？全都会触发ExceptionInInitializerError - 又如：
static Set<integer> VALID_CODES = new HashSet(Arrays.asList(Integer.parseInt("abc")));</integer>—— 字符串转整数失败，NumberFormatException被包装后上抛 - 更隐蔽的是：集合初始化依赖另一个尚未完成初始化的静态字段，造成隐式循环依赖，JVM 同样以初始化失败收场
常见“写死”写法与对应隐患
以下写法在启动期极易暴露问题，尤其在 Spring Boot 启动、单元测试 setup 或模块首次加载时：
-
硬编码 + 解析逻辑混写：
static Map<string string> CONFIG = parseJson("{...}");</string>——parseJson若未处理空输入或格式错误，直接崩 -
资源路径写死且无兜底：
static List<user> MOCK_USERS = loadFromCsv("/data/mock-users.csv");</user>—— 路径随打包方式变化（jar vs IDE），上线即挂 -
并发下误用非线程安全集合：
static List<string> NAMES = new ArrayList(); static { NAMES.add("A"); NAMES.add("B"); }</string>—— 看似安全，但若后续有其他静态块并发修改，可能引发ConcurrentModificationException
安全替代方案：不取消初始化，只推迟或加固
核心原则：静态上下文只做“确定性、零副作用”的事。集合初始化必须可诊断、可降级、可延迟。
-
改用懒加载单例：把集合封装进私有静态 holder 类或
Supplier，首次调用时才构建，失败可捕获并返回默认值或抛业务异常 -
静态 final 集合仅用构造器安全创建：如
static final Set<string> TYPES = Set.of("A", "B", "C");</string>—— Java 9+ 的工厂方法全程无异常，推荐用于纯字面量 -
初始化失败必须显式暴露：若必须在 static 块中加载，务必用 try-catch 包裹，并记录完整 cause（
e.getCause()），绝不能吞掉异常静默失败 -
外部化配置优先：用
@Value、@ConfigurationProperties或ResourceLoader替代硬编码路径，让 Spring 管理生命周期和错误传播
排查时盯住两个关键信号
别被表象带偏。遇到启动失败，先翻日志最开头：
- 搜
ExceptionInInitializerError—— 找到第一个出现的位置，它的getCause()才是真凶（比如FileNotFoundException） - 搜
NoClassDefFoundError: XxxUtil—— 很可能只是马甲，往上翻几屏，大概率能看到它依赖的类早先已因初始化失败被标记为 Erroneous
