ASP.NET Core 6+ 默认不启用 Brotli，需手动注册 BrotliCompressionProvider 并置于 Gzip 前以优先使用；注意 EnableForHttps 仅解除 HTTPS 禁用、MimeType 需包含 application/json、MinLength 合理设置、中间件顺序必须在 UseRouting 后 UseEndpoints 前，且响应体未提前写入。
ASP.NET Core 6+ 默认不启用 Brotli，得手动注册
ASP.NET Core 6 开始，BrotliCompressionProvider 不再随 AddResponseCompression() 自动注入，只默认带 GzipCompressionProvider。不显式添加，客户端发 Accept-Encoding: br 也会被忽略——响应里压根不会出现 Content-Encoding: br。
实操建议：
- 在
Program.cs的服务注册阶段，调用AddResponseCompression后，必须紧接着用AddBrotli（.NET 6+）或手动AddProvider<BrotliCompressionProvider>()（.NET 5 及更早） - 确认目标运行时支持：Brotli 需要
System.IO.Compression.Brotli包（.NET Core 3.0+ 内置，但 .NET Framework 不支持） - 浏览器兼容性不是问题，但老版 Postman 或某些测试工具可能没发
br请求头，建议用curl -H "Accept-Encoding: br" -I http://localhost:5000/api/test验证
配置 Gzip/Brotli 优先级要靠 Providers 注册顺序
压缩算法选择不是按客户端请求头里逗号分隔的顺序，而是看 CompressionProvider 在 ResponseCompressionOptions.Providers 列表里的位置——排前面的优先匹配。
常见错误现象：Accept-Encoding: gzip, br 却返回 gzip，不是因为浏览器写了 gzip 在前，而是你代码里先注册了 Gzip provider。
实操建议：
- 想让 Brotli 优先，就把
AddBrotli()放在AddGzip()前面 - 不要依赖
EnableForHttps全局开关，它只控制是否对 HTTPS 响应启用压缩，不影响算法选择逻辑 - 注意
MimeTypes配置：默认只压缩text/plain、text/css等，JSON 接口需手动加application/json，否则即使匹配了br也不压缩
ResponseCompressionOptions 的 EnableForHttps 是个坑
设成 true 并不等于“对所有 HTTPS 响应都压缩”，它只是解除框架对 HTTPS 响应的默认禁用；真正是否压缩，仍取决于 MimeTypes、Provider 是否匹配、响应体大小（默认 MinLength 是 2048 字节）等多个条件。
容易踩的坑：
- 本地开发用 HTTP 测试时，
EnableForHttps = true完全无效，但你可能误以为配置没生效 - 设成
false后，HTTPS 下连 Gzip 都不会触发，哪怕客户端明确请求了 -
MinLength太小会导致小响应（比如{"ok":true}）被反复压缩，反而增大体积；太大又错过优化机会，建议保持默认或设为 1024
中间件顺序错了，压缩就完全不工作
ResponseCompression 中间件必须放在 UseRouting 之后、UseEndpoints（或 UseAuthorization/UseAuthentication）之前。放错位置，比如插在 UseStaticFiles 后面，静态文件能压，但 API 响应就绕过了。
典型错误场景：
- 把
UseResponseCompression()放在UseExceptionHandler()之后 → 异常响应不走压缩 - 在 Minimal Hosting 模型中漏掉
app.UseResponseCompression()，只配了服务端注册 → 配置全白搭 - 用了
MapControllers()但没配AddControllersAsServices()，导致某些控制器响应绕过中间件链
最常被忽略的是：压缩只作用于未写入响应体的内容。如果某个中间件或控制器提前调用了 Response.Body.WriteAsync 或设置了 Response.ContentLength，后续压缩中间件会跳过——这在自定义流处理、大文件下载或 SignalR 场景下特别容易出问题。
