rate-limit 是一个用于实现或审计 Upstash Redis 限流策略的技能，定位为滥用与成本控制的一层，核心主张是先设计策略再接入中间件。
用途 该技能适用于需要保护路由、控制调用成本或审计已有 Upstash 限流实现的场景。它处理受信任的用户、租户、API Key 或 IP 标识，关注 429 响应头与存储故障时的行为。
工作流程 首先进行探测：识别 Next.js/运行时/版本、已部署的代理/CDN、鉴权或 API Key 模型、已安装的 Upstash 版本、受保护路由、操作成本、既有配额，以及中间件或代理是否已经接触请求。
然后定义策略表。按路由类分别列出：标识符、算法/窗口/突发量、成本权重、用户层级、响应行为与存储故障行为。只有在无法推断威胁与成本的权衡时才需要询问。
标识符信任模型 优先使用已认证用户、API Key 或租户+用户标识。仅对匿名流量使用 IP，并且只来自部署提供的可信来源。不要信任来自公网的任意 x-forwarded-for；配置可信代理深度与平台头。不要把未知客户端统一折叠为 127.0.0.1。
命名空间与分层 按环境以及路由/策略进行命名空间隔离。不要对同一请求同时应用全量中间件与逐路由限流器，除非有意的分层限流使用不同的键。
配置与故障行为 显式配置 Upstash 超时与日志/指标。按端点选择故障行为：低风险可用性路径可以在降级遥测的情况下放行；鉴权、高成本生成或对滥用敏感的路径可以使用本地应急限流、队列、额度预留，或明确关闭并返回清晰的临时响应。
响应与加权 返回 429，并带有非负的 Retry-After 与一致的限流响应头。在有用时为成功响应也添加响应头。在放行降级期间不要输出误导性的零限流值。对于加权工作，基于服务器计算的批量/操作成本消耗令牌。限流应与请求体大小限制、并发控制、幂等性、预算/额度以及相关提供方配额结合使用。
异步工作 当 SDK 暴露待处理 Promise 时，使用运行时的 waitUntil 机制保留分析同步等异步工作。
验证 使用确定性的测试与隔离的键前缀，尽可能使用可控时钟/窗口。测试允许/阻止/重置行为、路由隔离、已认证与匿名键、伪造转发头、付费/免费策略、并发、加权请求、存储超时/故障行为，以及避免重复中间件。运行仓库的 lint/type/test/build，仅在启用时检查 Upstash 分析。
输出 报告策略表、标识符信任模型、更改的文件/环境变量名、故障行为、响应头、分层控制、自动化测试证据，以及剩余的 Upstash/部署配置。
限制 资料未提供具体价格、平台支持范围、性能数据或独立基准结果。该技能要求依据实际部署环境进行配置，部分决策（如威胁与成本权衡）在无法推断时仍需人工确认。