SQL自定义错误码应采用XXYYY五位数字结构，前两位表大类（如05=业务逻辑约束），后三位表子类，需语义清晰、避免混淆值，并与SQLSTATE协同使用，配套文档、校验和版本管理确保可维护性。
SQL自定义错误代码不是随便编个数字就行，核心是建立可读、可维护、可扩展的分类体系。重点在于让错误码本身携带语义，便于开发、运维、日志分析和用户提示快速定位问题根源。
按错误性质分层编码：5位数字结构
推荐采用 XXYYY 五位数字格式：
- 前两位（XX）表示错误大类，如：01=语法错误、02=权限错误、03=数据完整性错误、04=连接与会话异常、05=业务逻辑约束失败
- 后三位（YYY）表示具体子类，在大类下递增分配，例如 03001=主键冲突、03002=外键引用不存在、03003=唯一索引重复
- 避免使用0或全9等易混淆值（如00000、99999），也不建议用负数或字母——保持纯数字利于日志解析、监控告警匹配和数据库函数兼容
与SQLSTATE协同使用，不替代标准规范
PostgreSQL/SQL Server等支持SQLSTATE（5字符标准码），自定义错误码应作为补充而非覆盖：
- 在RAISE EXCEPTION或THROW中同时提供SQLSTATE和自定义码，例如：RAISE EXCEPTION '用户余额不足' USING ERRCODE = 'P0001', HINT = 'ERR-05001';
- SQLSTATE用于通用分类（如P开头表示“PL/pgSQL异常”），自定义码ERR-05001则指向具体业务场景（如“支付扣款余额校验失败”）
- 应用层统一捕获时，优先用SQLSTATE做粗粒度路由，再用自定义码做精准处理或用户提示
业务错误单列一类，严禁混入系统错误范围
将“用户输入超长”“活动已结束”“库存不足”等明确属于业务规则的异常，全部划入独立大类（如05xxx），与数据库自身错误（01–04类）物理隔离：
- 便于前端区分展示：系统错误显示“服务异常，请稍后重试”，业务错误可直接提示“该手机号已注册”
- 避免DBA误将业务拒绝当作故障排查，也防止开发把约束违规当成正常流程忽略日志告警
- 新增业务规则时，只在05类下追加，不影响原有系统错误码体系稳定性
配套管理不可少：文档+校验+版本控制
错误码体系生命力取决于落地执行：
- 维护一份内部可查的error_code.csv或Confluence表格，包含字段：码值、类别名、含义、触发场景、建议修复方式、引入版本
- 在CI阶段加入SQL脚本扫描，禁止出现未登记的自定义ERRCODE字面量（可用正则匹配ERR-\d{5}并校验白名单）
- 跨服务调用时，错误码随API响应透出（如HTTP 400 body中带code: "ERR-05001"），前端和服务间约定仅消费已注册码，未知码按默认兜底策略处理
基本上就这些。不复杂但容易忽略的是持续维护——每上线一个新校验，就要同步登记错误码，否则半年后谁也说不清ERR-05187到底代表什么。
