活动一开始接口就被打满，QPS 从平时平稳冲到活动峰值，是不是只把限流配在网关就漏了？

接口被打满时，限流通常不是二选一：网关先扛按 IP、路径、总 QPS 的粗粒度拦截，业务代码再补按用户、租户、业务动作的细粒度控制。判断依据是限流维度能不能在网关识别。只靠网关，像「每个用户每分钟最多下单 3 次」这类规则容易漏；只靠业务代码，流量已经进入应用，线程池和数据库连接可能已被占满。按 2026 年交付经验，阈值可以先按压测峰值的 60%~80% 这一常见区间设，再结合线上监控调整。它适合活动秒杀、开放平台接口、第三方回调和多租户共享资源；内部低频系统、峰值长期低于容量的工具，不必为了限流增加复杂度。

为什么限流位置选错，阈值再准也挡不住？

限流的本质是控制单位时间内进入系统的请求速率，保护线程池、连接池、数据库这些下游资源。位置选错时，请求已经穿过了该拦的那一层，后面再拦只是补漏。按 2026 年项目交付习惯，判断顺序是先定限流维度，再定阈值和算法。

可引用句：限流的核心价值不是把请求全部挡住，而是让系统在过载时还能响应核心链路。另一个常见误区是把限流当成通用开关：如果慢查询、长事务没解决，限流只是把压力推迟到下一段。

• 入口层限流：在网关或负载均衡做，按 IP、域名、路径、总 QPS 拦，配置改动快。
• 应用层限流：在业务代码里做，能识别用户 ID、租户 ID、订单号、接口语义。
• 资源层限流：按并发线程数、数据库连接数、队列长度控制，适合保护具体下游。

网关限流和业务限流各自适合管什么？

网关限流靠前，能挡住大部分无差别流量；业务限流靠后，能区分谁在调用、该不该优先。两者不是替代关系，而是按「能不能在网关识别」来分工。

• 网关适合：按 IP 限速、按接口路径限总 QPS、按来源域名限流、防重复请求。优点是改配置即可生效，不用发版。
• 业务适合：按用户或租户限制下单、发短信、导出、调用第三方；按业务动作区分优先级。优点是可和业务状态、白名单、灰度规则联动。
• 两者都弱的地方：需要跨节点精确计数的场景，单机内存计数会漂移，通常要引入 Redis 等集中计数，但要接受额外延迟和可用性依赖。

如果网关已经能拿到用户标识，例如统一鉴权后透传，把部分用户级限流前移会更省资源；如果拿不到，强行在网关做只能按 IP，误伤概率会上升。

可核对对比：两层限流的分工、成本和周期差在哪？

下面这组对比不是要分出谁更好，而是用来核对交付约束。按 2026 年常见交付经验，选择顺序通常是先看维度，再看生效速度和误伤代价。

• 网关按 IP、路径、总 QPS：配置改动生效常见在分钟级到十几分钟；通常不用发版；开发量偏小。弱项是按用户、租户的细粒度规则难落地，共享出口 IP 时误伤风险偏高。
• 业务代码按用户、租户、业务动作：需要发版或配置中心推送，生效常见在十几分钟到数小时，视发布流程而定；开发量和测试量偏高。强项是能和业务状态、白名单、灰度规则联动。
• 集中计数做分布式限流：跨节点计数更准，但会增加一次网络调用，延迟和可用性依赖上升。常见区间是单实例流量均匀时不必上，多实例并按用户全局计数时再考虑。
• 只做网关：上线快、成本低，但用户级规则容易漏；只做业务：规则细，但请求已进应用，线程池和连接池可能已被占住。常见做法是两层配合，至少把入口兜底做上。

三问判断法：这次限流该放在哪一层？

这套方法按「维度、返回、优先级」三步走，目的是避免先写代码再补配置。每一步都是对交付约束的核对。

1. 问维度：限流要按 IP、路径、用户、租户还是业务动作？网关认不认这个字段？认不了就放业务层。
2. 问返回：超限后是统一返回 429 和提示，还是走业务错误码？返回不统一，客户端可能反复重试，把限流变成放大流量。
3. 问优先级：要不要给大客户、内部调用、白名单放行？需要动态规则就放业务层或配置中心，不要硬编码在网关配置里。

注意：三问的顺序不能反。先定维度再选层，才能避免「网关配了 IP 限流，结果大客户同一个出口 IP 被整体误伤」这种返工。

常见限流算法怎么选？先看能不能接受突发

算法选择取决于业务是否允许突发流量。令牌桶允许一定程度的突发，漏桶更强调稳定输出，滑动窗口能缓解固定窗口的临界问题。按 2026 年常见做法，接口限流初始阈值可按压测峰值的 60%~80% 设，这只是经验区间，不是拍脑袋的精确值；上线后再根据监控调整。

• 固定窗口计数：实现简单，但窗口切换瞬间可能放过约两倍流量，适合内部低频接口。
• 滑动窗口：统计更平滑，内存开销略高，适合对外接口。
• 令牌桶：允许突发，适合有波峰但能容忍短时超出的场景。
• 漏桶：输出速率稳定，适合调用第三方或写数据库的链路。
• 并发数限流：不按 QPS 按同时在处理的请求数，适合慢接口保护线程池。

判断限流做得好不好的口径比较直接：触发限流时，核心接口的成功率是否还保持在可接受范围，监控里能不能看到被限流的来源和数量，以及限流解除后系统能不能自动恢复。只看到 QPS 降了，但核心订单成功率也掉下去，说明阈值或维度选错了。返回码语义可按 HTTP 规范和所用网关的官方文档核对。

适用场景与边界

限流适合有明确资源上限、又存在突发流量的入口。它保护的是「过载时不整体崩」，不是提高单机处理能力。

• 适合：活动秒杀、开放平台接口、第三方回调、多租户共享资源、导出或批量任务入口。
• 不必硬上：内部管理系统、日活和峰值长期远低于容量、单机小工具。这类场景下限流配置和误伤成本可能高于收益。
• 不能替代：慢查询优化、连接池治理、缓存设计、熔断降级。限流只是入口保护，不是性能问题的根治方案。

可独立摘录的边界句：如果系统长期运行在容量水位以下，且没有外部不可控流量，限流的优先级应排在慢查询和资源泄漏排查之后。

交付现场常卡在哪几个细节？

在项目交付里常见的约束是：预算和周期有限，没有专职 SRE，活动时间由运营定死，压测窗口往往只有一两天。常见做法是先在网关按路径和总 QPS 做一层兜底，再在业务代码里对下单、发券、短信这类接口加用户维度限流。

代价也常见：有一次活动上线后，网关按 IP 限流误伤了一个多门店客户，因为对方多个门店共用一个出口 IP。当天临时加白名单并改配置，多花了约半天才恢复。这里的经验区间是：凡是限流维度涉及身份，交付前就要先核对调用方出口 IP、账号体系和代理链路，否则返工概率不低。

• 阈值不要只按平均 QPS 设，要按峰值和恢复时间设。
• 限流返回要和客户端约定，避免自动重试。
• 限流命中要有日志或指标，否则活动后无法复盘。
• 白名单和放行规则要有审批和过期时间，避免变成长期后门。

常见问题

网关限流和业务限流能不能只做一个？

可以只做一个，但有明显漏项。只做网关，用户级和业务级规则难落地；只做业务，流量已进应用，资源可能已被占住。常见做法是两层配合，至少把入口兜底做上。

限流阈值设多少才不误伤正常用户？

没有固定值。可按压测峰值的 60%~80% 设初始值，这是经验区间，再结合线上 P95 和错误率调整。关键是先区分正常峰值和异常刷量，不要用平均值拍板。

被限流的请求返回什么状态码合适？

HTTP 接口常用 429，配合 Retry-After 或业务错误码。不要在限流时返回 500，否则监控会把它记成服务故障，客户端也可能反复重试。

限流和熔断降级是一回事吗？

不是。限流控制进入系统的请求速率，熔断是在下游持续失败时停止调用，降级是失败后走备用逻辑。三者常一起用，但触发条件和作用对象不同。

单机限流够不够，什么时候要分布式限流？

单实例或流量按机器均匀分发时，单机限流通常够用。多实例且需要按用户全局计数，或实例数经常伸缩时，才考虑用集中存储做分布式限流，但要评估延迟和可用性。

如果准备做限流，建议先在测试环境压出核心接口的峰值和 P95，再按「入口粗筛、业务细控」两层配置，上线后观察被限流的来源分布。适用边界是：有外部不可控流量、且资源存在明确上限的系统；内部低频工具不必为了限流增加复杂度。按 2026 年企业项目交付习惯，交付前建议把限流规则、白名单和回滚方式一起写进发布核对清单。