网站遭遇异常请求时的限流策略，不该只有“拦”或“放”两种选项。一个读取静态说明的请求，与一次生成大报表、检索大量记录的请求，消耗的计算和存储资源差别很大。把所有路径都配置成同一档高规格防护，可能增加成本，也可能误伤正常用户。更实用的做法是按资源消耗、业务影响和防护位置分层。
先算清楚：哪些请求最贵、最不能停
先把接口按处理成本分组，不必一开始就购买或部署复杂组件。常见的低成本请求是读取固定内容；中等成本请求可能涉及数据库查询；高成本请求则包括批量导出、复杂搜索、文件转换等。分类应依据实际调用链和资源监控，而不是只看请求名称。
再判断业务优先级：登录、下单或提交关键表单通常需要保留容量；可稍后完成的报表、推荐刷新等任务，则可以延迟、排队或临时降级。网站遭遇异常请求时的限流策略，核心就是避免低优先级、高消耗任务挤占关键操作。
按成本从轻到重配置
第一层：给普通请求设基础边界
对资源开销较低、调用频率可预测的路径，可先使用按账号、会话或来源标识计数的基础规则。令牌桶适合允许短时突发、但限制长期平均速率的场景；固定窗口实现简单，但在窗口切换时可能出现短时间流量叠加。具体阈值应从正常高峰的监控数据起步，并留出业务增长和突发访问的余量，不宜照搬其他站点的数字。
第二层：对昂贵操作限制并发
批量导出或复杂查询不只消耗请求次数，还会长时间占用工作线程、数据库连接或内存。此时仅限制每分钟次数未必够，应增加并发上限、任务排队或单用户任务数限制。并发上限控制同时运行的任务数，优点是直接保护后端资源；缺点是超出后用户可能等待，因此要配合明确的排队反馈，并设置任务超时和取消机制。
第三层：再决定是否增加专用防护
若异常流量集中在入口、来源变化快，或基础规则仍无法保护源站，再评估边缘侧防护、托管限流或专用清洗能力。它们通常能更早拦截流量，但会带来服务费用、规则维护和误判排查成本。自适应限流可以依据延迟、错误率或资源水位动态收紧阈值，适合负载波动明显的系统；若监控信号不可靠，自动调整也可能造成反复限流，应先从告警和人工确认开始。
一套可执行的落地顺序
列出主要路径，记录请求量、响应时间、错误率，以及数据库、队列或计算资源的消耗。
标出关键操作与高成本操作，分别确定可接受的等待、拒绝和降级方式。
先为低风险路径设置基础速率限制，为重任务增加并发上限或排队，不要一次性套用全站同一阈值。
在测试环境或低风险路径验证规则；观察正常高峰、突发活动和重复提交时的效果，逐步调整阈值。
记录触发原因、路径和时间段，并设置人工解除或回退方案。若使用熔断，在依赖服务异常时应限制对该依赖的继续调用，恢复后再逐步放量。
按成本选择，别忽略误伤代价
小型、负载稳定的网站，应用层的基础计数和少数高成本接口的并发控制，往往更容易维护；流量来源复杂、入口容量有限或需要保护多处服务时，才更值得比较边缘防护与托管方案。评估时同时看费用、规则可控性、日志可见性、故障时的回退能力，以及正常用户被拒绝后的影响。网站遭遇异常请求时的限流策略，应先用低成本规则保护最容易被耗尽的资源，再根据监控证据升级，而不是为尚未出现的风险预先配置最重方案。
常见问题
限流阈值应该设成多少？
没有适用于所有站点的固定值。按路径观察正常高峰及资源余量，在可承受范围内逐步收紧，并通过告警和小流量验证减少误拦。
只按来源限制够不够？
不一定。用户可能共享网络出口，自动化请求也可能分散来源。可结合账号、会话、路径和行为特征，但要避免收集不必要的个人信息。
被限制后应该直接报错吗？
应提供清楚、可恢复的反馈。对可排队任务提示等待状态；对不可接受的请求说明稍后重试，并避免客户端立即高频重发。
什么时候需要升级防护？
当基础限流已启用，源站资源仍持续逼近容量、关键操作受影响，或维护规则的成本已高于托管方案成本时，再评估升级更合适。
