目标
团队精心打磨成功载荷却随手拼凑失败响应，于是客户端长出十二个分支的错误解析，每新增端点就多一支。审计是机械的：到处触发一个校验错误、记录响应体、给形状分类。报告让分歧无可辩驳，SDK 字段使用统计选出事实标准，再配一致性测试防止标准再次被侵蚀。
步骤要点
- 对每个端点 POST 空对象触发校验错误，用 jq 把“端点 + 响应体”逐行并排输出，形状差异立刻可见。
- 机械分类：按是否含 error/message/errors 字段归入 envelope、flat、rails-style 或 other。
- 统计客户端 SDK 源码中 .error/.message/.details/.code 的引用次数，让事实标准由真实使用投票选出。
- 定义目标封装（code/message/details）并给出兼容映射：字符串入 message、数组入 details、码入 code。
- 加一致性测试对每条路由断言错误封装形状，新端点不符合即构建失败，漂移无法再悄悄累积。
排错提示
部分错误返回纯文本或 HTML 是因为错误中间件没挂到那些路由，应把所有失败统一交给一个渲染 JSON 封装并设置正确 content-type 的处理器；客户端依赖旧形状就开新版本或在弃用窗口内双发新旧字段并公布下线日期；5xx 体内泄漏堆栈时，只返回可引用的关联 id，细节留在服务端日志。
适用边界
审计只能看到被触发的错误，未测分支仍可能偏离，因此一致性测试要覆盖全部路由而非抽样；统一封装只规范形状不规范语义，VALIDATION_FAILED 这类 code 仍需按端点写清文档。
代码示例
# Trigger and compare error bodies across endpoints
for ep in /orders /users /payments /search; do
curl -s -X POST "https://api.example.com$ep" \
-H "content-type: application/json" -d '{}' | jq -c "{ep: \"$ep\", body: .}"
done