asp.net core 6+ 默认不压缩任何响应，必须显式注册provider（如addbrotli/addgzip）、配置mimetypes（含application/json）、启用useresponsecompression中间件（位于userouting后、useendpoints前）、设置enableforhttps和minlength，缺一不可。
ASP.NET Core 6+ 默认完全不压缩任何响应，哪怕你装了包、调用了 AddResponseCompression()，只要没显式加 Provider、没配 MIME 类型、中间件顺序错，就等于没开。
为什么 AddResponseCompression() 调了还是没 Content-Encoding 头？
这是最常卡住人的点：服务注册 ≠ 压缩生效。框架只注册了空壳服务，不自动注入 GzipCompressionProvider 或 BrotliCompressionProvider。
- 必须手动添加 Provider：
options.Providers.Add<gzipcompressionprovider>()</gzipcompressionprovider>或.AddBrotli()（.NET 6+ 扩展方法） -
EnableForHttps = true不是“开启 HTTPS 压缩”，只是解除对 HTTPS 的默认禁用；HTTP 下它压根不生效 - 中间件
UseResponseCompression()必须放在UseRouting()之后、UseEndpoints()或UseAuthorization()之前——放错位置会被跳过 - 响应体一旦被提前写入（比如在中间件里直接
context.Response.WriteAsync()），压缩就彻底失效
怎么让 application/json 响应被压缩？
默认白名单里根本没有 application/json，只包含 text/plain、text/css、application/javascript 等。JSON 接口返回再大也不会压缩。
- 用
ResponseCompressionDefaults.MimeTypes.Concat(new[] { "application/json" })扩展类型列表，别用new string[]全量覆盖，否则 CSS/JS 反而不压了 - 大小写敏感：
"application/json"有效，"Application/Json"匹配失败 - 注意
MinLength默认是 2048 字节；小 JSON（如{"ok":true}）可能被跳过，可设为1024，但别设成1——压缩开销反而更大
为什么客户端发 Accept-Encoding: br, gzip 却返回 gzip？
不是浏览器决定的，是 Provider 在 options.Providers 列表里的注册顺序决定的。框架从头开始匹配第一个能处理该编码的 Provider。
- 想优先用 Brotli，就把
AddBrotli()放在AddGzip()前面 -
AddBrotli()在 .NET 6+ 是扩展方法，需确保引用了Microsoft.AspNetCore.ResponseCompression包 - 老版 Postman 或某些测试工具默认不发
br请求头，建议用curl -H "Accept-Encoding: br" -I http://localhost:5000/api/test验证 - Brotli 在 .NET Framework 上不支持，仅限 .NET Core 3.0+ / .NET 5+
为什么 UseStaticFiles() 的文件没被压缩？
静态文件中间件默认绕过整个请求管道，UseResponseCompression() 完全不生效。
- 这不是 bug，是设计使然；官方推荐由 Nginx、CDN 或 IIS 处理静态资源压缩
- 非要硬上，得在
UseStaticFiles()配置里加OnPrepareResponse手动写Vary: Accept-Encoding头，但内容本身仍不压缩 - 试图用
ResponseCompression压静态文件，属于用错工具——性能收益低，还增加 CPU 开销
真正容易被忽略的是：压缩是否生效，取决于 Provider 注册顺序、MIME 类型、响应体大小、中间件位置、协议类型（HTTP/HTTPS）、甚至响应是否已被写入——五个条件缺一不可。少配一个，Content-Encoding 就不会出现。
