ThrottledStream 是最直接的上传流限速方案，它在每次 Read 前检查速率并等待，不阻塞线程，仅拖慢读取节奏；需避免自行实现令牌桶时误用 DateTime.Now、锁竞争或高频补令牌，且 RateLimitingMiddleware 对上传无效。
用 ThrottledStream 包裹上传流是最直接的方案
不推荐自己从零实现令牌桶或漏桶——C# 生态已有成熟、轻量、线程安全的封装，比如 Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.ThrottledStream（内部类，不建议直接用），更现实的是采用社区验证过的 ThrottledStream（来自 NuGet 包 System.IO.Streams 或自行实现的简易版）。它的核心逻辑是：每次 Read 前检查是否允许读取指定字节数，若超出速率则等待，不阻塞整个请求，只拖慢流读取节奏。
常见错误现象：自己写 Thread.Sleep 控制间隔，结果在同步 I/O 下卡死整个线程；或在 async/await 中误用 Task.Delay 但没 await，导致限速失效。
- 使用场景：ASP.NET Core 中处理
IFormFile.OpenReadStream()返回的流，或HttpRequest.Body直接读取大文件时 - 必须包装在最外层读取点，例如：把原始
Stream传给new ThrottledStream(original, bytesPerSecond: 1024 * 1024) - 注意：
ThrottledStream通常不实现Seek，所以不能用于需要随机读取的场景（如 ZIP 解压前校验） - 性能影响极小，单次
Read调用增加约 50–200ns 的判断开销，远低于网络 I/O 本身
RateLimitingMiddleware 对上传无效，别被名字误导
ASP.NET Core 7+ 内置的 RateLimitingMiddleware 只作用于请求频次（requests per second）、并发连接数或 IP 级别，它在管道早期就完成判定，**完全不感知请求体大小或传输过程**。你配置了每秒最多 5 个上传请求，但每个请求仍可能瞬间打满带宽上传 500MB。
典型误用：在 Program.cs 里加了 app.UseRateLimiter() 就以为上传也受控，结果监控看到网卡跑满，而限流中间件日志里毫无异常。
- 该中间件触发点在
HttpContext.Request头解析完成后、Body 读取前，此时 Body 还没开始接收 - 它无法与
MultipartReader或FormReader协同做字节级节流 - 若真想结合请求级 + 流量级控制，需两层：外层用
RateLimitingMiddleware控制并发请求数，内层用ThrottledStream控制单个请求的上传速率
自实现令牌桶要小心 DateTime.UtcNow 和锁竞争
如果必须手写（例如嵌入非 ASP.NET 环境），令牌桶最简结构只需一个 long _availableTokens、一个 DateTime _lastRefill 和 refill 逻辑。但生产环境容易翻车的点很具体：
- 别用
DateTime.Now—— 时区和夏令时会导致_lastRefill计算错乱，必须用DateTime.UtcNow - 高并发下多个线程同时调用
Consume(long bytes)，必须用Interlocked操作_availableTokens，而非lock—— 否则上传峰值时锁争用会成为瓶颈 - 令牌补充频率别设太高（如每 1ms 补一次），系统时钟精度有限，高频更新反而导致抖动；推荐每 100ms 补一次，按比例折算令牌数
- 示例关键片段：
long now = DateTime.UtcNow.Ticks; long elapsedMs = (now - _lastRefill) / TimeSpan.TicksPerMillisecond; long tokensToAdd = (long)(elapsedMs * _bytesPerSecond / 1000.0); _interlocked.Add(ref _availableTokens, tokensToAdd); _lastRefill = now;
前端配合能缓解后端压力，但不能替代服务端限速
前端用 XMLHttpRequest.upload.onprogress 或 fetch + ReadableStream 分块上传，可以切片、暂停、重试，看起来“更可控”。但这只是用户体验优化，**所有分块仍走同一 TCP 连接，服务端不做流控的话，Nginx 或 Kestrel 仍会把数据全收进来再处理**。
真实踩坑：前端限制每秒发 1MB 分片，但服务端未对 Request.Body 做节流，Kestrel 缓冲区积压大量未处理数据，OOM 或超时断连。
- 必须服务端兜底：哪怕前端完全不可信（如被绕过、脚本篡改），也要保证单请求上传速率可控
- 若用 Nginx 做反向代理，可配
client_max_body_size和client_body_timeout，但它不支持动态速率限制，仅防恶意长连接 - 真正有效的组合是：前端分片 + 后端
ThrottledStream+ 反向代理连接超时兜底
实际部署时，最容易被忽略的是 ThrottledStream 生命周期管理——它必须和上传请求绑定，不能复用或静态持有，否则多个请求会互相干扰令牌计数。另外，HTTPS 加密开销会让实测速率略低于设定值，预留 5–10% 余量更稳妥。
