nginx原生不支持直接解析jwt或自动提取用户id，但可通过map提取header/cookie中的id、兜底空值、定义limit_req_zone并结合burst/nodelay在location中启用，实现按用户id的精细化限流。
直接用 limit_req_zone 对用户 ID 限流，Nginx 原生不支持“直接解析 JWT 或自动提取 uid”，但可以通过变量 + map + zone 的组合方式，把用户 ID 变成限流键，实现真正按人限流。关键不是“能不能”，而是“怎么构造稳定、唯一、非空的 key”。
从请求中可靠提取用户 ID
用户 ID 通常在请求头（如 X-User-ID）、Cookie（如 uid=12345）或由上游网关解密 JWT 后透传过来。Nginx 不解析 JWT，所以推荐由 API 网关提前处理并注入标准 header。
- 从 header 提取：
map $http_x_user_id $user_id {<br> default ""; <br> ~^(\d+)$ $1;<br>} - 从 Cookie 提取（需确保
http_cookie模块可用）：map $http_cookie $user_id {<br> default ""; <br> ~uid=(\d+) $1;<br>} - 空值必须兜底：若未登录或 header 缺失，
$user_id为空字符串，所有匿名请求会挤进同一个桶——建议设默认值，比如"guest_$(murmurhash($remote_addr))"（OpenResty）或简单用"anonymous"单独计数
定义用户级限流区域
用提取出的 $user_id 定义 zone，内存大小按活跃用户量估算（每个 key 约占 64 字节）：
-
limit_req_zone $user_id zone=user_limit:10m rate=5r/s;→ 每个用户每秒最多 5 次 - 若需区分等级（如免费/付费），先用 map 分类：
map $user_id $user_tier {<br> default "free";<br> ~^100[0-9]{3}$ "premium";<br>}<br>limit_req_zone $user_tier zone=tier_limit:5m rate=20r/s; - 千万级用户？单 zone 易驱逐 key，可分片：
limit_req_zone "$user_id$arg_v" zone=user_v1:5m rate=5r/s;（加版本号或哈希后缀分散）
在接口路径中启用并控制行为
限流策略要落在具体 location 中，burst 和 nodelay 的搭配决定用户体验和防御强度：
- 对登录、下单等敏感接口：
limit_req zone=user_limit burst=3 nodelay;→ 允许极小突发，超了立刻 503 - 对列表、详情等读接口：
limit_req zone=user_limit burst=20;→ 允许排队，不加 nodelay，避免响应延迟突增 - 统一返回状态码：
limit_req_status 429;→ 让客户端明确识别限流，而非 503 - 记录限流日志便于归因：
log_format main "... bid=\"$user_id\" limit_status=\"$limit_req_status\"";
其中$limit_req_status值为 0（放行）、1（延迟）、2（拒绝）
补充高阶控制能力
纯 Nginx 有边界，但可通过组合手段提升精度：
- 多维拼接：租户 ID + 模块名 →
set $biz_key "$http_x_tenant_id:$http_x_module";，再用于 zone - 分级限流：用多个 zone + if 判断 header（如
if ($http_x_plan = "pro") { limit_req zone=pro_limit; }），注意 if 在 location 中慎用 - 兜底方案：当用户量超内存上限或需动态配额时，应引入 Redis + Lua（OpenResty）或外部鉴权服务做决策，Nginx 退为执行层
