应使用map指令对URI语义化归一后限流，而非直接用$request_uri；例如将/product/123?sort=price和/product/123?sort=name统一为products_123，再通过limit_req_zone实现精准防护。
直接用 $request_uri 做限流键，容易被绕过、内存开销大、且无法区分带参和不带参的同一资源路径。真正稳妥的做法是结合 map 指令做语义化归一，再配合 limit_req_zone 实现精准防护。
核心思路是：把“缓存友好型 URI”提取成统一标识，而不是原样用 $request_uri
比如 /api/v1/products/123?sort=price 和 /api/v1/products/123?sort=name 实质访问的是同一个产品缓存资源，但 $request_uri 会当成两个不同 key，导致限流失效或误伤。
✅ 正确做法：用 map 提取缓存资源主干
在 http 块中定义：
map $request_uri $cache_key {
~^/api/v1/products/(\d+) products_$1;
~^/api/v1/categories/(\d+) categories_$1;
~^/static/(.+\.js|.+\.css) static_assets;
default $binary_remote_addr;
}这个 map 把高频缓存接口按业务维度抽象为稳定 key：
- 所有
/api/v1/products/{id}→ 统一为products_123 - 所有静态资源
.js/.css→ 归为static_assets - 其他请求默认回落到 IP 级兜底
✅ 定义缓存资源专用限流区
limit_req_zone $cache_key zone=cache_limit:10m rate=5r/s;
-
10m内存支持约 8 万个不同缓存资源键（如 10 万商品 ID） -
5r/s是单个缓存资源每秒最大处理速率，防穿透、防刷热 key
注意：不要用
$uri，它不带 query string，但也不做路径归一；更不能直接用$request_uri，它含完整参数，极易被构造出海量唯一值耗尽 zone 内存。
✅ 在 location 中启用并控制行为
location /api/ {
limit_req zone=cache_limit burst=15 nodelay;
proxy_pass http://backend;
}-
burst=15：允许最多 15 个请求排队（不延迟），超了直接拒绝（503 或自定义 429） -
nodelay：避免因排队引入响应延迟，保障缓存服务低延时特性
✅ 补充建议：区分冷热资源，加一层 IP 限流兜底
limit_req_zone $binary_remote_addr zone=ip_fallback:10m rate=100r/m;
location /api/ {
limit_req zone=cache_limit burst=15 nodelay;
limit_req zone=ip_fallback burst=50 nodelay; # 防止单 IP 刷多个缓存资源
proxy_pass http://backend;
}双层限制：既保单个热资源不被打穿，又防 IP 级横向扫描。
⚠️ 避免踩坑的几个关键点
- 不要在
if块里写limit_req—— Nginx 不支持，配置会加载失败 -
zone大小要预留余量：10MB ≈ 8 万 key，若商品 ID 达百万级，需调到20m或分片 - 开启日志记录限流状态，便于分析是否误杀或攻击特征：
log_format limitlog '$remote_addr - $remote_user [$time_local] "$request" $status $limit_req_status'; access_log /var/log/nginx/cache_limit.log limitlog;
- 若后端已做缓存（如 Redis），可适当放宽
rate，重点防穿透而非防并发
这样配置下来，对 /api/v1/products/123 的高频请求会被收敛到同一个 key 上精确限流，而不会因为加了不同参数就逃逸，真正守住缓存层命脉。
