4. 错误码规范:模块前缀、错误级别、自增编号、文档映射
错误码是跨模块 Result 封装中最核心的结构化字段。随意的错误编号会导致排查成本飙升、跨团队协作混乱。本章定义一套可落地的错误码规范,确保每个错误码在系统中具备唯一性、可读性与可追溯性。
4.1 错误码结构定义
规范采用四段式数字编码,每位字段之间使用短横线 - 连接:
| 字段 | 位数 | 说明 |
|---|---|---|
| 模块前缀 | 3 位数字 | 标识错误来源模块,如 001 ~ 999 |
| 错误级别 | 1 位数字 | 1=INFO, 2=WARN, 3=ERROR, 4=FATAL |
| 自增编号 | 4 位数字 | 每个模块独立自增,0001 ~ 9999 |
| 文档映射 | 2 位数字 | 指向在线 Wiki 或设计文档的章节 ID,00=无映射 |
示例:012-3-0024-01
012→ 用户中心模块3→ ERROR 级别0024→ 该模块第 24 个错误码01→ 文档 ID 为 user-center-01
4.2 编码示例与边界说明
模块前缀分配原则:前缀 000 保留给基础库框架错误;001~099 预留给网关与基础设施;100~999 按业务模块在架构评审时统一分配,禁止随意占用。
# 模块前缀注册表示例(截取)
Prefix | Module Name
-------|-------------------
000 | core-framework
001 | api-gateway
002 | auth-service
010 | payment-service
012 | user-center
013 | order-service
020 | notification-service
4.3 错误码生命周期与解析流程
下图展示一个错误从发生到被 Result 封装、再到文档映射的完整链路:
4.4 选型权衡与风险点
| 决策点 | 方案说明 | 风险 / 权衡 |
|---|---|---|
| 模块前缀位数 | 3 位十进制,最多 1000 个模块 | 10 位系统级前缀可能更灵活,但增加用户记忆成本;3 位对通用业务足够 |
| 错误级别位置 | 放在第二段便于日志筛选 | 将级别放在末尾更易阅读,但解析效率降低;按监管要求选择靠前位置 |
| 自增编号滚动 | 每个模块独立自增,不跨模块强制顺序 | 可能产生编号空洞;模块重建时若不清零会导致歧义——建议发布新版本时重置 |
| 文档映射 | 占用 2 位数作为索引 | 文档章节超过 99 时需要重新规划;文档链接不要硬编码在错误码中,而是映射表管理 |
4.5 落地步骤
- 确定模块前缀表:架构评审会上一次性分配所有业务模块前缀,写入
module_prefix.json。 - 建立自增编号池:每个模块在 Git 仓库中维护
errors/code_pool_XXX.yaml,记录已使用编号。 - 实现错误码生成器:封装一个工厂函数,传入模块前缀、级别、文档 ID,自动分配下一个可用编号。
自增编号冲突风险:多个开发者同时添加错误码时可能分配重复编号。建议采用流水线审批+PR 检查机制,在 CI 中对 code_pool 文件做唯一性校验。
# 伪代码示例:错误码生成器
function genErrorCode(moduleId, level, docId) {
pool = loadPool(moduleId)
nextSeq = pool.nextAvailableSeq() // 0401 格式
pool.markUsed(nextSeq)
savePool(pool)
return moduleId + '-' + level + '-' + nextSeq + '-' + docId
}
4.6 验收标准
| 验收项 | 通过标准 |
|---|---|
| 错误码唯一性 | 全量错误码全集扫描无重复,PR 合并前自动校验 |
| 模块前缀一致性 | 每个模块只使用已注册的前缀,非法前缀在 CI 中失败 |
| 文档映射可达性 | 映射表中每个 docId 都能解析到有效文档 URL,定期巡检 |
| 级别语义正确 | ERROR/FATAL 级别错误必须有日志与告警,INFO 级别不触发警报 |
| 编码格式解析 | Result.code 字段能被日志分析工具正确切分为四段 |