面试官看重的是对API失效边界的预判与分级响应能力，包括输入不可信、依赖不可靠、资源枯竭的应对策略，以及性能、语义、运维边界的清晰定义和主动承认局限性。
面试官真正想看的，不是你能不能画出一个漂亮的API接口图，而是你能否在设计之初就预判它会在哪些地方“垮掉”，又打算怎么兜住它。
健壮性不等于加个try-catch
很多候选人一提健壮性，就堆砌“日志完善”“异常捕获”“重试机制”——这些是基础动作，不是设计思维。面试官更关注你是否理解：健壮性本质是**对不确定性的分级响应能力**。
- 输入不可信：不只是校验手机号格式，还要考虑空字符串、超长Unicode、SQL注入式payload、时区错乱的时间戳；建议用JSON Schema做结构+语义双校验，而非仅靠后端if判断。
- 依赖不可靠：下游服务可能超时、返回空数据、甚至返回格式错乱的JSON；你要明确说明降级策略——是返回缓存？返回兜底值？还是直接熔断？每种选择对应的业务影响是什么。
- 资源会枯竭：内存、连接池、线程数、磁盘空间都不是无限的；健壮的设计必须包含主动限界（如最大并发数、单次请求最大body size）和可观测指标（如当前连接数占比、慢查询率）。
每个API都有它的“失效边界”
没有绝对健壮的API，只有清晰定义了失效边界的API。面试中能坦然说出“这个接口在QPS超过5000时会开始丢请求，因为数据库连接池已满”，比硬撑“我们做了全链路高可用”更有说服力。
- 性能边界：明确标注P99延迟、吞吐量拐点、压测瓶颈（比如Redis连接数打满、MySQL慢查询突增）。
-
语义边界：比如
/v1/orders支持创建订单，但不保证幂等——那就要在文档里写清“重复提交可能生成多笔订单”，而不是等线上出问题再补救。 - 运维边界：是否支持灰度发布？能否按用户ID哈希路由？配置变更是否需要重启？这些决定了它上线后到底有多“扛折腾”。
局限性不是缺陷，而是设计共识
面试官欣赏敢于说“这里不支持”的人。真正的专业感，来自对取舍的清醒认知。
- 不承诺强一致性：比如用户资料更新接口，可明确说明“头像修改后5秒内全站可见”，避免为毫秒级同步付出十倍成本。
- 不覆盖边缘场景：如“不支持跨时区批量导入含夏令时的时间数据”，比含糊其辞的“暂不支持”更可信。
- 不隐藏技术债：若当前用单库分表支撑千万用户，可直言“未来2年需迁移到分库分表，因此API设计预留了sharding_key字段”，这反而体现架构前瞻性。
归根结底，健壮性不是让系统永不失败，而是让失败变得可预期、可解释、可收敛。而承认局限性，恰恰是你对系统有真实掌控感的证明。
