我不会直接画架构图，会先确认目标、规模和一致性要求。比较固定窗口、滑动窗口、漏桶和令牌桶并设计多层限流。限流用于把进入系统的工作量控制在可承受范围。令牌桶允许按速率补充并容纳一定突发，漏桶把输出整形成稳定速率，滑动窗口比固定窗口更平滑。算法只是基础，关键是限流维度、阈值来源、分布式一致性和拒绝后的响应策略。 阈值应来自压测容量、依赖瓶颈和 SLO，并预留故障期间的容量余量，不能凭机器配置猜测。

容量有了以后，再把入口、核心处理和数据落点串起来。沿着「请求携带身份与资源维度 → 选择本地/集中限流器 → 原子消耗令牌或配额 → 超限快速失败/排队 → 动态调整并观测拒绝」观察输入、状态与输出，这些阶段都可以从日志、指标或源码里验证。 请求携带身份与资源维度 限流维度应包含用户、IP、租户、接口和下游资源，单维度容易误伤或被绕过。 选择本地/集中限流器 本地限流延迟低但总量不精确，集中限流全局一致但增加网络和热点。 网关限流决策日志：维度、规则、结果。 下游连接/线程水位：真实保护对象。 我会先确认请求实际走到了哪条路径，再用运行数据验证，不会只看类名或配置猜测。

关键参数要从峰值流量和资源上限反推。是否先从下游容量和业务优先级确定阈值。 能否比较常见限流算法的流量形态。 是否设计网关、服务、用户和资源多层配额。

正常链路之外，还要设计失败补偿和可验证的恢复流程。总 QPS 未超阈值，但一个昂贵查询占用远多于普通请求。引入按接口成本加权的并发许可，并以数据库连接与慢查询为反馈后，限流才对准真实瓶颈。 只限 QPS 不限并发和成本：放行/拒绝率：按下游可持续能力设阈值。 限流器故障时默认全放行：在途并发：限 QPS 同时限并发。 排队无上限导致超时雪崩：下游饱和水位：限流器故障保守降级。 固定输入和基线 先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「放行/拒绝」为主基线，记录值应满足「记录活动/稳态基线」；同时保存 放行/拒绝率、在途并发，使后续变化能够回到同一时间轴比较。

最后再讲扩容、成本和方案边界。方案：更适合的场景：主要收益：代价与边界。 固定窗口：简单计数和粗粒度配额：实现低成本：边界双倍突发。 滑动窗口：需要更精确速率：边界平滑：存储与计算更高。 令牌桶：允许短时突发的 API：吞吐与突发可配置：不直接限制在途并发。 选型至少带上 峰值流量、数据规模、依赖容量、一致性目标和故障预算，并用上面的量化基线验证；未知数据应明确为待测假设。