自研组件库通过结构化异常id（comp-模块名-场景码-版本号）和自动注册校验机制，实现lambda异常的可追溯、可收敛、可治理；强制使用exceptions.biz封装、全局拦截校验及ci/文档/监控配套保障。
在自研组件库中为 Lambda 内部异常赋予唯一 ID 并规范错误码，核心不是“防冲突”，而是建立可追溯、可收敛、可治理的异常标识体系。Lambda 本身无状态、生命周期短、调用链分散，若每个匿名函数或方法内随意 throw new RuntimeException("xxx")，错误码极易重复、语义模糊、无法归因。真正可行的做法，是把异常 ID 当作“异常指纹”，由组件库统一生成与校验，而非靠人工约定。
统一异常 ID 生成策略
不依赖人工编号，改用结构化拼接 + 全局注册校验：
-
格式固定为：COMP-模块名-场景码-版本号（例如
COMP-auth-login-fail-v2），其中模块名取自组件坐标（如 Maven groupId:artifactId），场景码用小写字母+下划线命名（避免数字开头歧义）； - 组件启动时扫描所有
@Component或@Service类中的静态ErrorCode常量，自动注册进内存注册表； - 若检测到重复 ID（相同字符串），启动失败并抛出
IllegalStateException，强制拦截问题于构建阶段。
Lambda 内部异常的封装姿势
禁止在 Lambda 表达式里直接 throw 原生异常。必须通过组件提供的工具方法包装：
- 提供
Exceptions.biz(String id, String message)工具方法，内部自动注入当前组件上下文（如模块名、调用栈浅层类名）； - 在 Lambda 中写法为：
list.stream().map(x -> { if (x == null) throw Exceptions.biz("login-fail", "用户凭证为空"); return x.process(); })； - 该方法会补全前缀
COMP-和版本号，生成完整 ID，并记录调用点（文件名+行号），供后续日志追踪。
全局抛出前的拦截与强化
利用 Spring 的 @RestControllerAdvice 拦截所有异常，但不止于分类响应——要对 Lambda 抛出的异常做二次校验：
- 检查异常是否为组件库封装的
ComponentException； - 提取其 ID 字段，查注册表确认是否合法且已注册；
- 若 ID 格式非法或未注册，自动降级为
COMP-unknown-runtime-error，并告警通知架构组； - 响应体中显式携带该唯一 ID 字段（非仅 code 数值），前端可直接上报用于错误聚类分析。
配套机制保障不漂移
单靠代码约束不够，需工程流程兜底：
- CI 流程中加入
error-code-checker插件，扫描源码中所有字符串字面量匹配COMP-[a-z0-9_-]+，比对注册表，缺失则构建失败； - 文档站点自动生成错误码清单页，按组件分组、支持搜索，每次发布自动更新；
- 日志采集端识别
error_id字段，自动打标至监控平台，同一 ID 的错误率突增即触发告警。
