resty.limit.count 是 openresty 官方推荐的动态限流方案，基于共享内存实现低延迟、高并发安全限流，支持运行时 key 构造与滑动窗口，需避坑初始化失败、key 爆炸、同步 redis 调用及 header 注入等问题。
nginx-lua 里用 resty.limit.count 做动态限流最稳
硬编码限流阈值在配置里根本没法应对流量突变，resty.limit.count 是 OpenResty 官方推荐的方案，底层用共享内存（shared dict）存计数器，不依赖外部服务，延迟低、并发安全。它不支持“按用户 ID 动态配额”，但能通过 Lua 变量拼接 key 实现运行时决定限流维度——比如从请求头取 X-User-Type，再查 Redis 拿该类型对应的 QPS 上限。
常见错误是直接把 limit:incoming() 返回值当布尔用：if limit:incoming() then ——其实它返回的是剩余请求数（数字）或 nil + 错误信息，必须显式判断是否为 nil。
- key 构造别用原始 IP 或未清洗的参数，防 key 爆炸（如带时间戳的 query 参数）
- 共享字典大小要预估：10 万 key × 128 字节 ≈ 12MB，设太小会频繁淘汰导致限流失效
-
limit:incoming()的第三个参数是「窗口大小」，单位秒；设 60 就是滑动窗口 60 秒，不是固定时间窗
从 Redis 加载动态阈值时，别在 access_by_lua_block 里同步调用
OpenResty 的 access_by_lua_block 是阻塞执行的，如果这里用 redis:connect() + redis:get() 同步拉阈值，一个慢查询就能拖垮整个 worker 进程。必须用 cosocket 异步方式，或者更稳妥地——把阈值缓存在 shared dict 里，定时用 timer.at 刷新。
典型场景：不同客户等级（free/premium）对应不同 API 调用上限，阈值存在 Redis 的 rate_limit:plan:{plan_name} 下。
立即学习“Python免费学习笔记（深入）”；
- 首次访问时异步触发加载，用
ngx.timer.at(0, load_threshold)避免阻塞 - shared dict 缓存过期时间设比 Redis TTL 短 1–2 秒，防止缓存击穿
- Redis 连接池必须复用：
redis:set_keepalive()不要漏，否则连接数暴涨
Python 服务如何安全传参给 nginx-lua？重点防 header 注入
Python 后端往 upstream 透传限流相关字段（如 X-Quota-Key、X-Quota-Limit），不能直接把用户可控输入塞进 header。比如用户提交 user_id=abc%0d%0aX-Injected:，Nginx 解析时可能截断或误判。
使用场景：Python 做鉴权后，根据 JWT payload 决定该请求走哪个限流策略，再通过 proxy_set_header 把策略标识透传给 lua 模块。
- header 名必须全小写且只含字母数字和短横线，
X-Quota-Key合规，X-Quota-Key!会被 nginx 丢弃 - 值要做白名单过滤：只保留
[a-zA-Z0-9_.-]，其余统一替换成下划线 - 不要传 raw token 或完整 JSON，传 hash(
user_id+plan) 即可，lua 侧用同样逻辑还原 key
limit.count:new() 初始化失败的三个信号
初始化失败不会抛异常，而是让后续 incoming() 返回 nil + 错误字符串，容易被忽略。真正要检查的是 limit.count:new() 的返回值本身：
- 返回
nil+"failed to create the 'resty.limit.count' instance"→ 共享字典名写错，或没在http{}块里定义lua_shared_dict my_limit_dict 10m; - 返回
nil+"invalid window"→ 第三个参数（窗口秒数）不是正整数，比如传了0或60.5 - 返回对象但
limit:incoming()总是nil→ key 字符串为空或全是空白符，lua 里string.match(key, "%S") == nil就是这个症状
复杂点在于：同一个 shared dict 可被多个限流实例共用，但 key 命名空间不隔离——count:new("my_dict", 100, 60) 和 conn:new("my_dict", 10) 会互相污染。别图省事混用字典。
