单机接口阶梯式限流的核心是让滑动窗口适配业务节奏：利用固定500ms子窗口特性，通过规则链（qps+线程数+动态降级）、上下文分流（普通/vip/搜索）、预检延时放行等手段组合实现“正常→预警→收缩”的三级响应。
单机接口做阶梯式限流，核心不是堆规则，而是让滑动窗口“听懂业务节奏”——它本身不支持阶梯，但你可以用流程控制把它“编排”出阶梯效果。
理解滑动窗口的硬约束
Sentinel 的滑动窗口是固定 1 秒切 2 格（每格 500ms），不可配置。这意味着：
- QPS=1 时，实际表现常是前 500ms 放行 1 次、后 500ms 全拒，不是均匀分布；
- 它天然适合中高 QPS（≥20）场景，低频请求下抖动明显；
- 所谓“阶梯”，不能靠改窗口参数实现，得靠多层规则+条件判断来组合。
用规则链模拟阶梯：QPS + 线程数双维度兜底
单一 QPS 规则在低频时不准，那就叠加一层更稳定的维度：
- 第一层：QPS=5（适用于突发小高峰，比如用户点提交按钮连点几次）；
- 第二层：线程数=2（grade=0），防慢接口堆积，避免因响应慢导致请求数虚高；
- 第三层（可选）：加一个 fallback 降级逻辑，当连续 3 次触发 blockHandler，自动切换到更保守的 QPS=2 规则（通过 DynamicRulePublisher 动态推送）。
这样就形成了“正常→预警→收缩”的三级响应，而不是一刀切限流。
按请求特征分流，让窗口“分而治之”
同一个接口，不同用户/场景容忍度不同。别把所有流量塞进一个窗口统计：
- 对普通用户：走默认 QPS=10 的滑动窗口；
- 对 VIP 用户或内部调用：用 ContextUtil.enter("vip") 切换上下文，单独配 QPS=30；
- 对搜索类接口（耗 CPU）：加一个 @SentinelResource(fallback = "searchFallback")，并在 fallback 里记录日志+触发熔断计数，变相拉长“感知窗口”。
本质是把一个大窗口，拆成多个逻辑子窗口，每个子窗口按需设置阈值。
用预检+延时放行实现软阶梯
对特别敏感的操作（如支付确认），可绕过纯统计，加一层轻量预判：
- 在 Sentinel 的 Slot 链中插入自定义 FlowSlot，检查最近 10 秒内该用户是否已成功请求 ≥3 次；
- 若是，不直接拒绝，而是返回 202 Accepted + 延迟 500ms 后再执行（用 CompletableFuture.delayedExecutor 实现）；
- 这个“延迟窗口”和 Sentinel 的 500ms 子窗口错开，形成人为缓冲带，视觉上就是“越频繁，等待越久”，即阶梯感。
不增加统计负担，又让体验更平滑。
