Web应用的响应体积直接决定了用户的首屏体验，一段没有压缩的JSON数据可能有几百KB，经过压缩后往往只剩几十KB，传输量能下降70%以上。在ASP.NET Core中，微软提供了内置的响应压缩中间件，支持Gzip和Brotli两种算法，配置起来非常简单，但背后有不少值得深挖的细节，比如算法选择、压缩等级、MIME过滤和性能权衡。本文从原理到实践，带你完整掌握这套优化手段。
一、响应压缩的工作原理与算法选择
响应压缩的核心思路是：服务器在把响应体发送给客户端之前，先用压缩算法把它压成更小的体积，同时在响应头中加上Content-Encoding标记，浏览器收到后自动解压还原。整个过程对前端完全透明，因为现代浏览器都原生支持Gzip和Brotli解码，只需要在请求头中通过Accept-Encoding声明自己支持的算法即可。
Gzip诞生于上世纪90年代，基于DEFLATE算法，压缩速度快、兼容性极好，几乎覆盖所有客户端。Brotli则是Google在2015年推出的算法，采用了更新的哈夫曼编码和字典技术，对文本类内容的压缩率通常比Gzip高出15%到25%，尤其擅长HTML、CSS、JS这类内容。两者在压缩率上的差异来源于Brotli内置的预定义字典，短字符串可以直接用字典索引表示，不需要像Gzip那样必须完整编码。
选择建议很直接：面向现代浏览器的Web API和站点，优先启用Brotli，同时保留Gzip作为兜底，中间件会根据请求头自动协商最优算法。如果你的客户端包含老式设备或非HTTP环境，Gzip仍然是更稳妥的选择。ASP.NET Core默认引入了这两种Provider，开箱即用。
二、在ASP.NET Core中配置响应压缩中间件
响应压缩通过Microsoft.AspNetCore.ResponseCompression包提供（.NET Core 3.0之后已内置在框架中，不需要额外安装NuGet包）。启用方式分为全局中间件和Minimal API两种，下面看最常用的配置代码：
var builder = WebApplication.CreateBuilder(args);
// 注册响应压缩服务
builder.Services.AddResponseCompression(options =>
{
// 启用内存压缩，动态生成的响应也会被压缩
options.EnableForHttps = true;
options.Providers.Add<BrotliCompressionProvider>();
options.Providers.Add<GzipCompressionProvider>();
options.MimeTypes = new[]
{
"text/plain",
"text/css",
"text/html",
"application/json",
"application/javascript",
"image/svg+xml"
};
});
// 单独配置Brotli的压缩等级
builder.Services.Configure<BrotliCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Optimal; // 最高压缩率
});
builder.Services.Configure<GzipCompressionProviderOptions>(options =>
{
options.Level = CompressionLevel.Fastest; // 最快速度
});
var app = builder.Build();
// 注意：中间件顺序要在路由之前，才能压缩MVC返回的内容
app.UseResponseCompression();
app.MapGet("/api/data", () =>
{
return Results.Json(new
{
Message = "这是一段较长的测试数据，用于验证压缩效果",
Items = Enumerable.Range(1, 1000).Select(i => new { Id = i, Name = $"项目{i}" })
});
});
app.Run();
这段代码有几个关键点。第一，EnableForHttps必须显式设为true，默认值是false。微软这么设计是出于安全考虑：HTTPS下启用压缩理论上存在BREACH攻击风险（攻击者可借助压缩比猜测加密内容），如果你的响应中包含敏感信息例如CSRF Token，需要评估风险后再开启。第二，中间件的注册顺序很重要，UseResponseCompression要放在UseRouting和执行管道之前，否则实际写出的响应不会经过压缩处理。
MIME类型的过滤也值得注意。默认配置只压缩text/plain和text/html，JSON、JS、CSS都不在列表里，所以必须像上面那样手动补全。同时不要把已经压缩过的格式加进去，例如PNG、JPEG、ZIP，对这些内容再做压缩不仅浪费CPU，体积还可能不降反升。
三、压缩等级调优与常见坑点排查
压缩等级是一个典型的CPU与带宽的权衡问题。Brotli支持0到11共12个等级，等级越高压缩率越好但耗时急剧上升。实测中等级4到5在压缩率和速度之间取得了不错的平衡，适合动态请求；等级11虽然压缩率最高，但耗时可能是等级5的十倍以上，只建议用于可以缓存的静态资源预压缩。Gzip的Optimal大约对应等级6，Fastest对应等级1，动态接口建议用Fastest或SmallestSize折中。
验证压缩是否生效很简单，用curl或者浏览器开发者工具查看响应头即可：
curl -I -H "Accept-Encoding: br,gzip" https://localhost:5001/api/data # 正常情况下应能看到类似响应头： # Content-Encoding: br # Vary: Accept-Encoding
如果发现响应没有被压缩，按照以下顺序排查：先确认请求头里是否带了Accept-Encoding，没有的话中间件会直接跳过压缩；再检查响应的Content-Type是否在MimeTypes白名单中；然后确认HTTPS环境下EnableForHttps是否开启；最后检查中间件注册顺序。另外一个容易忽略的点是响应体积，中间件默认对小于一定体积的响应不做压缩处理，因为太小的内容压缩收益覆盖不了开销。
对于高并发场景，还需要关注压缩带来的CPU压力。如果服务器CPU经常因为压缩打满，可以考虑三个方案：降低压缩等级、只对静态文件做预压缩（利用WebApplication的静态文件中间件直接提供.br和.gz预生成文件），或者把压缩卸载到Nginx、CDN等反向代理层去做，让应用服务器专注于业务逻辑。
总的来说，响应压缩是投入产出比极高的一项优化，几行配置就能让接口传输体积下降大半。掌握Brotli与Gzip的特性和调优方法，再结合反向代理和静态资源预压缩策略，你的应用在网络传输层面就能达到一个相当专业的水平。