静态代码块初始化集合极危险：因JVM要求初始化“原子成功”，任何异常（如文件不存在、解析失败、循环依赖）均触发ExceptionInInitializerError，致类永久不可用；应改用懒加载、Set.of()安全构造或外部化配置。

静态代码块里初始化集合，看似省事，实则埋雷——一旦出错，类直接“胎死腹中”，后续任何引用都抛 ExceptionInInitializerError，甚至伪装成 NoClassDefFoundError，让人误以为是类路径问题。

为什么集合“写死”在 static 块里特别危险

集合初始化常伴随高风险操作：读配置、解析 JSON、查数据库、调用工具方法。这些动作在类加载阶段执行，而 JVM 对初始化要求“原子成功”——中间哪怕抛一个 NumberFormatException 或 IOException，整个类立刻进入“错误状态”，永不可恢复。

• 例如：static List ROLES = Files.readAllLines(Paths.get("roles.txt")); —— 文件不存在？权限不足？编码异常？全都会触发 ExceptionInInitializerError
• 又如：static Set VALID_CODES = new HashSet(Arrays.asList(Integer.parseInt("abc"))); —— 字符串转整数失败，NumberFormatException 被包装后上抛
• 更隐蔽的是：集合初始化依赖另一个尚未完成初始化的静态字段，造成隐式循环依赖，JVM 同样以初始化失败收场

常见“写死”写法与对应隐患

以下写法在启动期极易暴露问题，尤其在 Spring Boot 启动、单元测试 setup 或模块首次加载时：

• 硬编码 + 解析逻辑混写：static Map CONFIG = parseJson("{...}"); —— parseJson 若未处理空输入或格式错误，直接崩
• 资源路径写死且无兜底：static List MOCK_USERS = loadFromCsv("/data/mock-users.csv"); —— 路径随打包方式变化（jar vs IDE），上线即挂
• 并发下误用非线程安全集合：static List NAMES = new ArrayList(); static { NAMES.add("A"); NAMES.add("B"); } —— 看似安全，但若后续有其他静态块并发修改，可能引发 ConcurrentModificationException

安全替代方案：不取消初始化，只推迟或加固

核心原则：静态上下文只做“确定性、零副作用”的事。集合初始化必须可诊断、可降级、可延迟。

• 改用懒加载单例：把集合封装进私有静态 holder 类或 Supplier，首次调用时才构建，失败可捕获并返回默认值或抛业务异常
• 静态 final 集合仅用构造器安全创建：如 static final Set TYPES = Set.of("A", "B", "C"); —— Java 9+ 的工厂方法全程无异常，推荐用于纯字面量
• 初始化失败必须显式暴露：若必须在 static 块中加载，务必用 try-catch 包裹，并记录完整 cause（e.getCause()），绝不能吞掉异常静默失败
• 外部化配置优先：用 @Value、@ConfigurationProperties 或 ResourceLoader 替代硬编码路径，让 Spring 管理生命周期和错误传播

排查时盯住两个关键信号

别被表象带偏。遇到启动失败，先翻日志最开头：

• 搜 ExceptionInInitializerError —— 找到第一个出现的位置，它的 getCause() 才是真凶（比如 FileNotFoundException）
• 搜 NoClassDefFoundError: XxxUtil —— 很可能只是马甲，往上翻几屏，大概率能看到它依赖的类早先已因初始化失败被标记为 Erroneous