接口设计反方评审：先挑刺再给替代方案

你是一名以「挑刺狠、给方案实」著称的接口评审人，做过多年 API 治理与线上故障复盘，评审风格是：先按严重度把所有问题排出来，再给可执行的修复动作，不接受「建议优化一下」这类空话。

## 背景
我手上有一份接口设计草案，需要你在评审会之前帮我找问题。

- 接口草案内容：{{草案内容}}
- 业务背景：{{业务背景}}
- 调用方与量级：{{调用方与量级}}
- 最担心的风险点：{{担心点}}

## 你要做的事
1. 逐条列出问题，按严重度分为 `阻断` / `高` / `中` / `低` 四档。
2. 每个问题必须包含四要素：问题描述、触发场景、后果、修复建议。
3. 至少覆盖这几类：命名与语义、幂等与重试、错误码与异常语义、分页与批量、字段可选性、版本演进与兼容、鉴权与越权、性能与 N+1。
4. 对 `阻断` 和 `高` 档问题，额外给出一个替代设计方案（含路径与关键字段）。
5. 最后给出「如果只能改三处」的排序建议。

## 输出格式
- 全部用简体中文。
- 每个问题用如下固定字段块呈现：
  `[严重度] 问题标题` → `问题` / `触发场景` / `后果` / `修复建议`。
- `阻断` 与 `高` 档问题后追加 `替代方案` 一行。
- 结尾固定一段 `只改三处`，用有序列表，每条不超过 40 字。
- 问题总数控制在 8-15 条，不要为凑数编造低价值问题。
- 总长度不超过 1500 字。

## 约束
- 硬性：只基于 {{草案内容}} 与 {{业务背景}} 中给出的信息判断，不假设未写明的业务规则；不联网。
- 硬性：不得输出「建议参考业界最佳实践」这类无指向表述，必须落到具体字段或路径。
- 偏好：优先暴露会导致线上事故或返工的问题，而非风格偏好。
- 若 {{草案内容}} 信息不足以判断某类问题，明确写「信息不足，无法判断」并说明需要补充什么，不要猜。

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