doccker 接口契约安全规范
触发场景
- 新增或调整 HTTP/JSON 接口
- 前后端联调
- 列表页、分页、筛选项、状态枚举或详情页异常
- 前端开始兼容多种 response shape
- 后端某些接口没有走项目统一成功响应 helper
核心原则
- 先看真实接口输入输出，再下结论，不根据前端类型或旧记忆推测
- 能修后端契约根因时，优先统一后端；前端兼容只作为短期过渡
- 列表、详情、选项或枚举接口应遵守同一套成功响应格式
- 分页结构必须明确约定，不长期混用数组和分页对象
- 临时兼容可以保留，但必须写清退出条件和移除时机
检查清单
1. 成功响应包装
- 列表接口是否走项目统一成功响应 helper
- 详情接口是否也走同一成功响应格式
- 状态选项、枚举、筛选项接口是否仍在返回裸数组或其他特例结构
- 错误响应是否与项目现有模式一致
2. 列表与分页结构
- 前端当前期望的是数组、分页对象还是统一包裹后的
data - 后端真实返回是否与该期望一致
-
page、pageSize、total、items或等价字段是否完整且命名一致 - 页码基准是否一致，例如从 0 开始还是从 1 开始
3. 筛选项与枚举来源
- 筛选项接口返回的数据是否来自真实日志或真实状态字段
- “筛选项为空”是否真的是无数据，而不是契约失配
- 枚举值是否与列表数据里的真实值一致
- 前端回退生成选项时，是否已标注为短期兜底而非长期正式来源
4. 字段映射与调用链
- 前端使用的字段名来自真实接口返回，而不是本地类型猜测
- 列表、详情、筛选接口引用的是同一业务字段语义
- 若存在中间转换层，转换前后字段语义是否保持一致
5. 临时兼容治理
- 当前兼容分支是为了解什么具体问题
- 兼容分支的退出条件是什么
- 后端统一后是否有计划删掉双格式兼容
- 输出里是否明确区分“根因修复”和“短期兜底”
6. 验证
- 直接查看真实接口响应或服务端日志，而不是只看前端表现
- 验证列表、详情、筛选项三个入口是否都一致
- 验证空态、非空态和异常态下的契约表现
- 若保留兼容分支，验证其不会掩盖新的契约错误
常见反模式
- 看到页面能打开，就接受前端长期兼容数组和分页对象两种格式
- 只修列表接口，不修详情接口和状态选项接口
- 看到筛选项为空，就先从当前页数据回填，但不追查后端契约
- 在没有证据的情况下根据类型定义猜测字段名或返回结构
输出要求
- 明确区分症状、当前契约、期望契约、根因修复、临时兼容和退出条件
- 若证据来自日志、抓包或直接接口返回，要明确写出依据
- 若仍保留兼容逻辑，要说明为什么这次不立即删除