促销日突发状况：部分老用户刚打开页面就收到“请求过于频繁”的提示，客服也陆续接到反馈，反映点击几下就操作失败。事后复盘发现，问题源头在前一晚——为应对异常刷单流量，运维将某接口的限流阈值从每秒两百次下调至每秒五十次。异常流量确实被拦截了，但正常用户的浏览、加购和查询请求也一并被挡在门外。限流阈值调低后误伤正常用户，往往不是规则本身写错，而是调整过程中缺少分步校准。
先明确限流对象，再讨论阈值高低
阈值调低后出现误伤，第一步不是急着恢复原值，而是确认限流究竟拦住了谁。常见维度有四种：按用户账号限流，影响单个用户的操作频次；按IP限流，影响同一出口下的所有访问者；按接口限流，影响所有调用该接口的业务；按设备指纹限流，影响同一台设备上的多次请求。四种维度命中的范围差异很大。如果规则同时叠加了用户和IP两个维度，一个办公室共用出口IP，就可能因为其中一人操作频繁，导致整个办公室的人都被拦截。先把命中范围梳理清楚，才能判断误伤是来自阈值本身，还是来自维度叠加。
核对正常请求的特征基线
限流阈值不能凭感觉设定，要回到正常请求的实际分布。需要核对三项基线：峰值时段出现在几点到几点，平均每分钟请求频次是多少，合理突发区间有多大。比如查询类接口，用户连续翻页可能在一分钟内产生十几次请求，这属于正常突发；而提交类接口，同一用户短时间内重复提交几十次，才更可能是异常。基线数据应取自近期的真实访问日志，并区分不同业务场景。促销日的正常峰值往往高于平日，如果直接沿用平日的阈值，误伤几乎必然发生。
分步校准，先灰度再固定
确认基线之后，不要一次性把阈值调回原位，而是分步校准。第一步，先灰度放量，把阈值提高百分之二十到三十，只对部分用户或部分时段生效，观察拦截量变化。第二步，观察误伤率，重点看被拦截请求中，有多少来自已登录的老用户、有多少来自正常业务路径。如果误伤率明显下降，说明阈值偏低是主因。第三步，在连续观察一到两个完整业务周期后，再固定阈值，并保留小幅浮动空间。整个过程要避免在流量高峰期做大幅调整，否则很难区分是阈值问题还是流量本身波动。
调整前后的检查清单
每次调整限流规则前后，建议核对以下项目：白名单是否覆盖内部测试账号和合作方回调地址；告警是否配置了拦截量突增提醒；回滚条件是否明确，比如误伤率超过设定比例就自动恢复上一版阈值；调整记录是否写明了调整人、调整时间和调整原因。这些检查项看起来琐碎，但能在误伤发生时快速定位和恢复。it数运在软件维护实践中也强调，限流规则的每次变更都应留下可追溯的记录，方便后续复盘。
限流是保护手段，不是惩罚手段
限流的目的，是保护接口和数据库不被异常流量拖垮，而不是惩罚正常用户。阈值调低之后出现误伤，说明保护力度和正常业务需求之间失去了平衡。校准的依据应当来自官方文档说明、实际压测数据和真实访问日志，而不是凭经验拍一个数字。如果业务场景复杂，建议把限流规则按接口分级管理，核心接口从严，查询接口从宽。具体情况应以相关官方规定和专业人士意见为准。把限流当成一道需要持续校准的阀门，而不是一堵固定的墙，才能在挡住异常的同时，不让正常用户被误伤。
