自定义函数式接口需加@criticalbridgeinterface注解并写明强依赖关系，ci强制检查注解，ide模板自动插入，否则易被误删致运行时异常、堆栈失真或npe。
自定义函数式接口本身不带注解，团队协作中若缺乏明确标识和文档约束，极易被误认为“普通工具类”或“冗余代码”而删除，进而引发生产环境大面积异常。这不是语法错误，而是协作语义断层导致的系统性风险。
为什么删了就出事？关键在调用链隐蔽性
这类接口常被用于桥接受检异常（如 ThrowingSupplier
- 调用方代码看似只用了标准 Function 或 Consumer，实际背后是通过静态适配器调用你的自定义接口
- 删除该接口后，编译可能仍通过（适配器里用了 RuntimeException 包装），但运行时抛出的异常类型、堆栈深度、日志上下文全变了
- 最危险的是静默失效场景：比如适配器里返回 Optional.empty()，上游逻辑没做空判断，直接 NPE
如何让团队一眼认出“这不能删”
靠口头约定或文档说明远远不够，必须把约束嵌入开发流程：
- 给接口加专属注解，例如 @CriticalBridgeInterface，并在 JavaDoc 明确写“此接口被 XXX 模块的适配器方法强依赖，删除将导致异常处理逻辑降级”
- 在 CI 流程中加入检查：用正则扫描所有 @FunctionalInterface 类，强制要求包含指定注解或特定关键词注释，否则构建失败
- 在 IDE 中配置 Live Template，新建函数式接口时自动插入标准头部注释和占位注解，降低遗漏概率
补救措施：从日志和堆栈反向定位
如果已发生误删且线上报错，别急着回滚，先确认影响范围：
- 查错误日志中是否出现原本不该出现的异常类型，比如 RuntimeException 包裹的 IOException，但堆栈里找不到你熟悉的适配器方法名
- 搜索代码库中所有调用了 ThrowingXXX 开头方法的地方，逐个检查其返回值是否被下游安全消费（是否判空、是否捕获包装异常）
- 用 Arthas 的 sc -d 命令在线确认类是否还加载在 JVM 中；若已消失，再结合 git blame 查最近谁修改过相关包路径
长期防御：把“可删性”变成显式契约
与其事后追责，不如提前定义清楚哪些代码是“基础设施级”的：
- 在项目根目录放 ARCHITECTURE.md，列出所有被多模块引用的函数式接口，并标注生命周期责任人
- 对这类接口启用 @Deprecated 注解仅作过渡，真正要淘汰时，必须配套提供替代方案并更新所有调用点
- 在 PR 模板中增加检查项：“本次变更是否涉及核心函数式接口？是否已同步更新适配器和调用方？”
