目标
限流配置很容易悄悄失效：键选错、多进程下计数器各自为政、代理剥掉了客户端退避所需的响应头。本食谱用一次受控的并发突发测试，把“配置里写了限流”变成“限流真实生效”的证据，并确认被限流时返回 429 与退避头。
步骤要点
- 先审查限流器配置：确认 windowMs、limit 与存储后端，例如 60 秒窗口内最多 100 次。
- 用 hey 发起 300 次并发 30 的突发请求，只看状态码分布：应约为 100 个 200 与 200 个 429。
- 对被限流的响应检查 RateLimit-Remaining、RateLimit-Reset 或 Retry-After 头，确认客户端有退避依据。
- 等待窗口过期后再发 10 个请求，全部应回到 200，证明计数器会重置而不是永久累积。
- 多进程部署时把计数器迁移到 Redis 共享存储，重跑突发测试确认总量阈值仍然成立。
排错提示
全部放行通常是每个进程各持一份内存计数器，改用共享存储；本机有效而线上无效多半是取错客户端 IP，需要正确配置 trust proxy 或按认证主体限流；压测端自身连接数不足会产生连接错误，先降低并发或调高描述符限制再下结论。
适用边界
负载生成器测的是整条链路，后端变慢会掩盖限流效果，断言要看状态码而非延迟；按 IP 限流会误伤运营商级 NAT 之后的用户，生产环境应结合 API key 或账户等级作为限流键。
代码示例
hey -n 300 -c 30 -m GET https://staging.example.com/api/search -o /dev/null
# Status code distribution:
# [200] 100 responses
# [429] 200 responses