asp.net core 6+ 默认不压缩响应，需手动注册brotli/gzip provider、扩展mime类型（如application/json）、设置minlength并确保useresponsecompression()位置正确（userouting后、useendpoints前）。
ASP.NET Core 6+ 默认完全不压缩响应，哪怕你调了 AddResponseCompression()、装了包、写了中间件，只要 Provider 没注册、MIME 类型没扩、中间件顺序错，就等于没开。
为什么 AddResponseCompression() 调了但没 Content-Encoding 头？
框架只注册了一个空壳服务，AddResponseCompression() 不会自动注入任何压缩 Provider。Gzip 和 Brotli 都得手动加。
-
options.Providers.Add<gzipcompressionprovider>()</gzipcompressionprovider>是基础，必须显式写 - .NET 6+ 推荐优先用 Brotli：
options.Providers.AddBrotli()（需引用Microsoft.AspNetCore.ResponseCompression包） - Provider 注册顺序决定算法优先级：客户端发
Accept-Encoding: br, gzip，但返回gzip，大概率是你先注册了 Gzip - 别漏掉
builder.Services.Configure<gzipcompressionprovideroptions>(...)</gzipcompressionprovideroptions>或BrotliCompressionProviderOptions，否则用默认压缩等级（可能不是Optimal）
怎么让 application/json 响应被压缩？
默认 MIME 白名单里压根没有 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——压缩开销反而更大
UseResponseCompression() 放错位置就彻底失效
它必须在 UseRouting() 之后、UseEndpoints() 或 UseAuthorization() 之前。放错等于没写。
- 常见错误：放在
UseStaticFiles()之前 → 静态文件仍不压缩（因为UseStaticFiles()绕过整个中间件管道） - 更隐蔽的坑：在中间件里提前写响应体，比如
context.Response.WriteAsync("xxx")，后续压缩直接放弃 -
EnableForHttps = true不是“开启 HTTPS 压缩”，只是解除对 HTTPS 的默认禁用；HTTP 下设成true完全无效，本地调试时容易误判配置失败
为什么静态文件没被压缩？
UseStaticFiles() 默认不走中间件管道，UseResponseCompression() 对它完全不可见。
- 别指望框架自动压缩
wwwroot下的 JS/CSS —— 它们不会经过压缩中间件 - 生产环境应交由 Nginx、CDN 或反向代理处理静态资源压缩，更高效也更可控
- 若真要在应用层强制压缩，需自定义中间件拦截静态路径，并手动调用
CompressionProvider，但代价高、易出错，不推荐
最容易被忽略的是：Provider 注册顺序、MIME 类型扩展方式、以及 MinLength 和实际响应体大小之间的隐性匹配关系——三者一错，压缩就静默失效，连日志都不会报错。
