asp.net core 7+ 原生限流需显式注册策略并启用，fixedwindowratelimiter 是唯一开箱即用实现；漏注册、名不匹配或中间件顺序错误（须在 userouting() 后、useendpoints() 前）均导致限流完全失效。
ASP.NET Core 7+ 原生 RateLimiter 中间件必须显式注册策略 + 显式启用，漏掉任一环节，限流就完全不生效——不是“效果弱”，而是压根没进限流逻辑。
FixedWindowRateLimiter 必须用 AddFixedWindowLimiter 注册并配对策略名
只调用 AddRateLimiter() 而不注册具体限流器类型，运行时会抛出 InvalidOperationException: No rate limiter policy is configured。固定窗口是唯一开箱即用的内置实现，其他如滑动窗口、令牌桶在 .NET 8/9 中仍无官方具体类型（SlidingWindowRateLimiter 仅是抽象基类，不可实例化）。
-
AddFixedWindowLimiter("fixed", opt => { ... })中的"fixed"是策略名，后续所有绑定都依赖它，大小写敏感 -
Window必须是TimeSpan，推荐写成TimeSpan.FromMinutes(1)或TimeSpan.FromSeconds(30)，避免硬编码毫秒数（如60000）导致语义模糊或单位错误 -
PermitLimit表示该窗口内允许的总请求数（非并发数），比如设为100就是“每分钟最多 100 次请求” -
QueueLimit = 0表示不排队，超限直接返回429 Too Many Requests；设为正数会启用内存队列，但高并发下可能引发 OOM
UseRateLimiter() 的位置和参数必须严格匹配
中间件本身不会自动扫描策略，也不会 fallback 到默认策略。它必须在正确顺序中挂载，并且明确指定策略名（全局启用）或通过特性/路由链式调用（按端点启用）。
- 必须放在
UseRouting()之后、UseEndpoints()（或UseAuthorization()）之前；放错位置会导致HttpContext.GetEndpoint()返回null，策略无法解析 - 全局启用需传入策略名：
app.UseRateLimiter("fixed")，名称必须与AddFixedWindowLimiter("fixed", ...)中第一个参数**完全一致** - 若只想对部分路由限流，不能靠全局
UseRateLimiter()，而应在MapGet后链式调用RequireRateLimiting("fixed")，例如：app.MapGet("/api/data", () => "ok").RequireRateLimiting("fixed") - 控制器或 Action 上可用
[EnableRateLimiting("per-api")]特性，但该策略名也必须已注册，否则该端点不受限——这不是 bug，是设计行为
别信“原生支持滑动窗口”的文档或示例
截至 2026 年 5 月，.NET 官方 Microsoft.AspNetCore.RateLimiting 包中仍**没有提供开箱即用的滑动窗口限流器**。所有声称 AddSlidingWindowLimiter 可用的代码都会编译失败。
-
SlidingWindowRateLimiter类型仅作为抽象基类存在，无公开构造函数，也无法通过扩展方法注册 - 自行实现需维护多个时间桶（如 10 个 6 秒桶）、处理跨桶聚合、保证多线程安全——极易引入时钟漂移、计数丢失或内存泄漏
- 生产环境更现实的做法是：用
StackExchange.Redis+ Lua 脚本实现分布式滑动窗口，或改用已归档但稳定可用的AspNetCoreRateLimit（基于内存或 Redis，支持滑动窗口规则）
调试时最该确认的三件事
限流没反应？先别改逻辑，直接验证这三点是否全满足：
- 策略是否注册：检查
Program.cs中是否有AddFixedWindowLimiter("xxx", ...)，且没被注释或条件编译屏蔽 - 中间件是否启用：确认
UseRateLimiter("xxx")已调用，且"xxx"和注册名完全一致；或确认RequireRateLimiting("xxx")已链式附加到目标端点 - 顺序是否正确：用临时日志确认执行路径，例如在
UseRateLimiter()前后加app.Use(async (ctx, next) => { Console.WriteLine("Before RateLimiter"); await next(); });，看是否真走到这步
最容易被忽略的是策略名拼错（比如写成 "fixd"）或 UseRateLimiter() 放在 UseRouting() 之前——这时中间件连 Endpoint 都拿不到，自然不会触发任何策略检查。
