asp.net core 8+ 固定窗口限流必须显式调用 addfixedwindowlimiter 注册策略并正确配置 useratelimiter 中间件，否则抛 invalidoperationexception；策略名大小写敏感，中间件顺序须在 userouting 后、useendpoints 前；其固有临界突增缺陷使其仅适用于低精度场景。
ASP.NET Core 8+ 中固定窗口限流必须显式注册策略并绑定中间件，只调用 AddRateLimiter 不指定具体限流器类型会导致运行时报 InvalidOperationException: No rate limiter policy is configured。
必须用 AddFixedWindowLimiter 注册策略，不能只调用 AddRateLimiter
原生 RateLimiter 是抽象容器，不自带任何具体实现。固定窗口限流靠 FixedWindowRateLimiter，它只在你显式调用 AddFixedWindowLimiter 时才被注入。
- 错误写法：
services.AddRateLimiter(options => { });—— 没注册任何策略，启动就炸 - 正确写法：必须指定策略名（如
"fixed"）和配置委托，Window推荐用TimeSpan.FromMinutes(1)而非硬写毫秒数 -
PermitLimit是窗口内总允许请求数，不是并发数；它不控制并发线程，只计请求频次 -
QueueLimit = 0表示不排队，超限时直接返回429 Too Many Requests，避免堆积
UseRateLimiter() 必须放在 UseRouting() 之后、UseEndpoints() 之前
中间件顺序错位会导致限流完全不生效，且无报错、无日志——请求像没经过限流一样直通。
- 漏掉
UseRateLimiter()：所有请求绕过限流，策略白注册 - 策略名大小写敏感：注册时是
"fixed"，UseRateLimiter("fixed")写成"Fixed"就失效 - 若需按路由或 Header 区分策略，得用
ConfigureRateLimiter+EndpointRouteBuilder动态匹配，不能只靠全局策略
固定窗口的临界突增问题无法靠配置规避，得从业务层补救
比如每分钟限 100 次，用户可能在第 59 秒发 100 次、第 60 秒又发 100 次——两秒内 200 次，这是算法固有缺陷，不是代码写错了。
- 它适合对精度要求不高、流量较平稳的管理后台接口
- 不适合支付、下单等强一致性场景；这类场景必须上滑动窗口或令牌桶
- 生产中若坚持用固定窗口，建议搭配前端防抖 + 后端幂等 Key（如
requestId或IP+Endpoint+UserId组合）双重拦截 - 别依赖
MemoryCache做分布式限流——节点间不同步，集群下形同虚设
固定窗口真正难的不是写法，而是意识到它“不是万能的”：窗口边界不可控、不支持分布式、无法平滑削峰。一旦业务出现临界突增或跨节点协同需求，就得切到 Redis + Lua 的滑动窗口，而不是硬调参数去“凑”。
