核心是动态对齐后端真实处理能力，需差异化设置阈值（如短接口用rate+burst、长接口叠加limit_conn）、基于健康状态反向调节限流、按业务身份精准限流，并建立闭环验证机制。
保障 API 限流与后端性能匹配，核心是让限流策略“跟得上”后端真实处理能力，而不是拍脑袋设个数字。限流太松，起不到保护作用；限流太紧，又会误伤正常流量。关键在于动态对齐、分层控制和可观测反馈。
按接口特性差异化设置限流阈值
不同接口的资源消耗差异很大，统一限流容易失衡。比如登录接口 CPU 密集、耗时短，适合高频率+低 burst；报表导出接口 I/O 密集、耗时长，应限制并发数而非单纯速率。
- 对短平快接口（如 /login、/health）：用 rate + burst 控制请求频次，例如
rate=10r/s burst=20，允许短暂突发但不堆积 - 对长耗时接口（如 /export、/batch-process）：在 location 中叠加 limit_conn，例如
limit_conn peruser 3，防止单用户占满线程池 - 对读多写少的查询接口（如 /search）：可适当提高 rate，但配合 proxy_buffering off 避免 Nginx 缓存放大后端压力
用后端健康状态反向调节限流强度
限流不能只看请求量，更要感知后端是否已开始疲软。Nginx 可通过主动探测和响应反馈，动态收紧或放宽限流窗口。
- 在 upstream 中启用 health_check，例如
check interval=2 rise=2 fall=3 timeout=1，及时剔除慢节点 - 配置 proxy_next_upstream 包含
error timeout http_503，让失败请求自动转发到健康节点，避免单点雪崩 - 进阶做法：用 Lua 脚本读取后端上报的 RT 或错误率（如从 Prometheus 拉取），当某节点平均响应时间 >600ms 时，临时将其
weight降为 1，变相降低该节点承接流量比例
基于真实调用方身份做精准限流
只按 IP 限流在 NAT 或 CDN 场景下极易误杀。必须把限流粒度落到业务身份上，才能和后端服务的实际负载模型对齐。
- 优先使用请求头标识，如
$http_x_api_key或$http_authorization，定义 zone：limit_req_zone $http_x_api_key zone=perkey:10m rate=20r/s - 若需解析 JWT 中的
client_id或sub，配合lua-resty-jwt在access_by_lua_block中提取并 set 到变量，再供限流模块引用 - 保留一层宽松的 IP 限流兜底（如
rate=100r/m），防止无合法凭证的扫描或爬虫绕过主规则
建立限流效果闭环验证机制
限流不是配完就完事，必须持续验证它是否真正在保护后端，而不是制造新瓶颈。
- 开启 limit_req_log_level warn，把被限流请求记入 error log，配合日志分析统计命中率
- 暴露 Prometheus 指标，如
nginx_http_limit_req_rejected_total和后端http_server_requests_seconds_sum对比，判断限流是否滞后于性能拐点 - 定期做压测：模拟真实流量特征（如 80% 请求集中在 20% 的 key 上），观察限流触发时机与后端 CPU/DB 连接数峰值是否同步
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
