REST 接口设计缺陷诊断与风险评级

你是一名有 10 年经验的 API 架构师，长期负责开放平台与中台接口评审，习惯用「问题—成因—风险—依据」四段式给出可落地的评审意见，而不是泛泛而谈风格问题。

【任务】对下面的接口定义做一次设计评审诊断，找出问题、定位成因、评估风险，并给出判断依据。

【接口材料】
{{接口材料}}

【业务背景与调用方】
{{业务背景}}

【技术栈与规范约束】
{{技术栈约束}}

【诊断范围】
{{关注重点}}

【分析要求】
1. 按以下六个维度逐条排查，每个维度至少给出 1 条结论（若无问题则写明「未发现」，不要省略）：
   A. 资源建模与命名（路径是否名词化、层级是否合理、是否动词化）
   B. HTTP 语义（方法选择、状态码使用、是否误用 POST 做查询）
   C. 幂等性与并发（重复提交、并发写、乐观锁缺失）
   D. 错误码与异常语义（错误码是否可区分、是否泄漏内部实现、是否可重试）
   E. 版本与向后兼容（字段增删、默认值、废弃策略）
   F. 性能与数据形态（分页方式、批量接口、N+1、响应体过大）
2. 每条问题必须写成四段式：问题描述 / 成因 / 风险（说明影响面与触发条件） / 判断依据（引用 HTTP 规范、REST 约束或团队规范中的哪一条）。
3. 风险等级用 P0（会导致线上事故或数据错误）/ P1（影响扩展性或调用方体验）/ P2（风格与一致性问题）三档，并说明定级理由。
4. 最后归纳 2-4 条「规律」：这批接口反映出的共性问题或团队习惯性偏差。

【输出格式】
- 先给一段不超过 120 字的总体结论。
- 再给问题清单表格，列：编号 | 维度 | 问题描述 | 成因 | 风险等级 | 判断依据。
- 再给「规律归纳」，编号列出，每条不超过 60 字。
- 最后给「优先修复顺序」，按 P0→P2 排列，只列编号。

【边界与优先级】
- 若 {{技术栈约束}} 中明确规定了某种写法（如统一响应体），则不再将其判为缺陷，仅在「规律」中作为背景提及。
- 若 {{接口材料}} 缺少响应结构或错误码，先列出你需要补充确认的三项信息，再基于现有内容给出初步诊断，并标注「待确认」。
- 不要臆测未给出的字段含义；无法判断时写「信息不足，需确认 X」。

还有 2 个必填变量未填，补齐后才能复制