接口设计挑刺
在写代码之前，先找出设计漏洞
这是我的接口设计：[粘贴设计]。请以审查者的身份挑刺：1）列出 5 个最可能在实现时出问题的点；2）指出哪些字段是冗余的、哪些缺失会导致客户端二次请求；3）给出向后兼容的修改建议；4）如果这个设计有明显的更简单替代方案，直接说出来。
适合什么场景
- 接口还没有外部客户端在用，或只有内部一个调用方：此时改动成本最低。
- 前端和移动端要并行开发，你需要先把契约钉死再开工。
不适合的场景
- 接口已上线且有第三方在用：先谈兼容与灰度，挑刺的收益低于迁移方案。
- 分歧在业务语义（这个字段到底算不算退款），不在接口形状：先问产品。
示例
输入
GET /api/v1/orders?user_id=123
200 {"orders":[{"id":1,"status":"paid","items":[{"sku":"A1","qty":2,"price":1990}]}]}
客户端：首页只要订单数和最近 3 条，详情页再拉明细。你会得到
挑出列表内嵌完整 items，导致首页为了 3 条订单拉回全部明细（payload 与 N+1 同时变大）；缺游标分页和总数；status 用裸字符串，将来加状态会破坏客户端解析。建议列表返回摘要、`GET /orders/{id}` 返回明细，并保留 v1 字段以免破坏已有调用。常见误用
- 只贴成功响应示例，不写错误码、空列表、分页边界：挑刺会漏掉一半真正会出事的分支。
- 把挑刺当成「让它重写」：收到 5 条意见就照单全收，没确认哪条和自己的业务约束冲突。
可以这样改
- 补一句「假设这个接口要支撑 3 年后 10 倍流量，且 Web 和 App 两端共用」，能逼出分页和版本化问题。
- 要求「每条批评附一个具体的坏客户端代码示例」，能过滤掉抽象的架构说教。