限流、熔断、降级经常一起出现在面试里，但很多回答会把它们混成一团：流量大了限流，下游挂了熔断，不重要的功能降级。方向没错，但不够。真正的系统设计要回答：先保护谁，什么条件触发，牺牲哪些体验，什么时候恢复。
稳定性设计不是让系统永远不失败，而是在失败不可避免时，让故障范围可控，让核心链路优先活下来。
限流解决的是入口压力
限流主要面对的是请求量超过系统承载能力。它可以发生在网关、接口、用户、IP、租户、业务动作等不同维度。高并发活动、恶意请求、客户端 bug、批量任务误触发，都可能需要限流。
限流策略要贴业务。登录接口可以按用户和 IP 限制，支付接口可以按用户和订单限制，开放 API 可以按租户配额限制。不能只说“用令牌桶”，还要说明限流后返回什么、用户能否重试、是否需要排队或降级展示。
熔断保护的是下游依赖
熔断通常发生在下游持续失败或变慢时。继续调用只会占住线程、放大重试、压垮对方。熔断的目的，是短时间停止调用失败依赖，让系统快速失败或走降级路径。
熔断不是永久断开。它需要半开探测和恢复机制：过一段时间放少量请求试探，如果成功率恢复，再逐步放开。如果没有恢复机制，熔断会变成手动开关；如果恢复太激进，又可能让下游再次被打垮。
降级体现业务取舍
降级不是技术动作，而是产品和业务取舍。推荐服务不可用时，可以展示默认列表；评论服务慢时，可以先隐藏评论；风控服务异常时，支付可能不能随便放行。不同业务的降级边界完全不同。
面试里要避免一句“返回兜底数据”解决所有问题。兜底数据是否会误导用户？旧数据能不能接受？核心流程能不能继续？这些都要结合业务判断。对于金融、权限、库存这类场景，错误放行比失败更危险。
三者要一起观测
限流、熔断、降级都需要监控。限流次数上升，可能说明流量异常；熔断频繁触发，说明下游健康有问题；降级比例过高，说明用户体验已经明显受影响。只配置规则不看指标，等于不知道系统在牺牲什么。
一个更成熟的回答可以是：入口流量过载时限流，依赖持续失败时熔断，非核心能力无法保证时降级；三者都要有阈值、恢复策略、告警和业务可接受边界。这样讲出来，面试官听到的是稳定性设计，而不是背组件名。
这类题还可以补“恢复顺序”。故障恢复后，不要立刻把限流、熔断和降级全部撤掉。可以先放少量流量观察错误率和延迟，再逐步恢复。尤其是下游刚恢复时，如果瞬间放开积压请求，可能再次把对方打挂。
面试里把恢复过程讲出来，会比只讲触发条件更完整。稳定性方案不只是出事时挡一下，还要让系统能平稳回到正常状态。
如果简历里写了高并发项目，还可以准备一个具体例子：活动页可以降级推荐、评论和个性化，但不能让库存扣减绕过校验；查询类接口可以返回缓存，写入类接口要更谨慎。能把“哪些能牺牲、哪些不能牺牲”讲清楚，答案就不再是组件八股。