唯一异常id管理核心是建立可追溯、可收敛、可验证的错误码生命周期管控机制，通过结构化标识符、任务层自动注入、编译期强校验及线程池钩子绑定实现。
在自研组件库中实现唯一异常 ID 管理线程池异常，核心不是“生成随机ID”，而是建立可追溯、可收敛、可验证的错误码生命周期管控机制。重点在于避免人工定义冲突、跨模块覆盖、版本升级错位这三类典型问题。
一、异常 ID 的生成必须绑定上下文元信息
不依赖纯数字或字符串枚举，而是用结构化标识符，例如：
TP-POOL-0012-DBCONN-TIMEOUT
其中：
• TP-POOL：组件域前缀（Thread Pool）
• 0012：该组件内全局唯一、不可重用的序号（由 CI 脚本自动分配并校验）
• DBCONN：异常触发子模块（如 DataSourceWrapper）
• TIMEOUT：异常语义分类（非堆栈关键词，是业务可观测维度）
这种格式天然支持分段检索、日志聚合、告警路由，且杜绝了不同模块用相同数字（如“0012”）表示不同含义的问题。
二、线程池任务执行层强制注入 ID 绑定逻辑
不能靠开发者手动 setAttribute 或 throw new XxxException("TP-POOL-0012...")。应在任务封装环节统一拦截：
- 所有提交到线程池的任务，必须经由组件提供的
SafeTask.of(Runnable)或TracedCallable.of(Callable)包装 - 包装器内部自动读取当前调用栈中的
@TraceId注解、MDC 中的 traceId、或线程本地ComponentContext.getErrorCodeScope() - 若未显式声明 scope，则 fallback 到默认池级 ID 域（如
TP-POOL-DEFAULT），并记录 WARN 日志提醒收敛
三、校验与发布阶段阻断冲突
异常 ID 不是运行时行为，而是编译期契约。需在组件构建流水线中嵌入强校验：
- 扫描所有
new XxxException(...)和@ErrorCode("...")注解，提取全部 ID 字符串 - 比对 Git 历史，确认新增 ID 未在任何已发布版本中出现过（使用 SHA256 哈希存档历史 ID 集合）
- 若检测到重复或格式非法（如缺前缀、含空格、超长），CI 直接失败，禁止发布
四、线程池钩子中完成 ID 与状态的最终绑定
在 afterExecute(Runnable, Throwable) 中不只记录日志，而是补全可观测链路：
- 若
Throwable是组件标准异常基类（如ComponentRuntimeException），直接提取其内置 ID - 若为原始 JDK 异常（如
NullPointerException），则根据当前任务所属模块、线程名前缀、执行耗时等维度，映射到预定义的兜底 ID（如TP-POOL-9999-UNCAUGHT-NPE），并打上isFallback=true标记 - 将 ID 注入 MDC，确保后续日志、Metrics、Trace 全链路携带，且可被中央告警系统按 ID 聚合去重
