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 封装、再到文档映射的完整链路:

错误码生命周期:从发生到文档映射 错误发生 错误码生成器 Result 包装 业务逻辑 文档映射 问题排查与索引 模块前缀+自增编号 确保唯一性 文档映射字段 指向 Wiki 章节

4.4 选型权衡与风险点

决策点方案说明风险 / 权衡
模块前缀位数 3 位十进制,最多 1000 个模块 10 位系统级前缀可能更灵活,但增加用户记忆成本;3 位对通用业务足够
错误级别位置 放在第二段便于日志筛选 将级别放在末尾更易阅读,但解析效率降低;按监管要求选择靠前位置
自增编号滚动 每个模块独立自增,不跨模块强制顺序 可能产生编号空洞;模块重建时若不清零会导致歧义——建议发布新版本时重置
文档映射 占用 2 位数作为索引 文档章节超过 99 时需要重新规划;文档链接不要硬编码在错误码中,而是映射表管理

4.5 落地步骤

  1. 确定模块前缀表:架构评审会上一次性分配所有业务模块前缀,写入 module_prefix.json。
  2. 建立自增编号池:每个模块在 Git 仓库中维护 errors/code_pool_XXX.yaml,记录已使用编号。
  3. 实现错误码生成器:封装一个工厂函数,传入模块前缀、级别、文档 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 字段能被日志分析工具正确切分为四段