Output Caching 在 ASP.NET Core 8 中必须显式启用
ASP.NET Core 8 默认不启用 Output Caching，即使你加了
[ResponseCache]或
[EnableOutputCaching]，请求也不会被缓存——因为底层服务根本没注册。必须在
Program.cs中调用
AddOutputCache()并配置中间件。 漏掉
builder.Services.AddOutputCache()→ 缓存完全不生效，且无任何警告或错误 漏掉
app.UseOutputCache()→ 中间件链断开，缓存策略被跳过 若同时用了
UseResponseCaching()（旧版 API），需彻底移除，它与 Output Caching 冲突
控制器方法上启用缓存的两种等效写法
推荐直接使用
[EnableOutputCaching]特性，它比旧的
[ResponseCache]更精确、支持更多策略（如基于查询参数或自定义键的缓存）。
[EnableOutputCaching]：启用默认策略（60 秒，响应体全量缓存）
[EnableOutputCaching(Duration = 300)]：指定 5 分钟缓存时间
[EnableOutputCaching(PolicyName = "MyPolicy")]：引用命名策略（适合复用或集中管理）
[ResponseCache]仍能工作，但仅触发基础 HTTP 缓存头（
Cache-Control），不走内存/分布式缓存后端，也不支持键变换等高级功能
缓存键生成逻辑容易被忽略的细节
Output Caching 默认按 HTTP 方法 + 请求路径 + 查询字符串 + 请求头（如
Accept、
Accept-Encoding）生成缓存键。这意味着： 带不同查询参数的请求（如
/api/items?id=1和
/api/items?id=2）默认视为不同缓存项 客户端发来
Accept: application/json和
Accept: text/plain会分别缓存 若想忽略某些查询参数（如跟踪用的
utm_source），需自定义策略：
policy.AddBasePolicy(builder => builder.Expire(TimeSpan.FromMinutes(10)).VaryByQuery("id"))
不建议用 VaryByAll，它会让每个请求都生成新缓存项，等于没缓存
调试缓存是否生效的关键信号
光看响应头不够，要确认缓存真正命中。最直接的方式是观察日志和响应头组合：
启用日志：在appsettings.Development.json中设置
"Microsoft.AspNetCore.OutputCaching": "Information"命中缓存时，日志中会出现
Cache hit for key 'xxx'；未命中则为
Cache miss响应头中出现
X-Output-Cache: Hit（或
Miss）是 Output Caching 的专属标识，比
Age或
Cache-Control更可靠 注意：POST/PUT 等非安全方法默认不缓存，即使加了特性也无效——这是设计限制，不是 bug 缓存策略的粒度控制（比如按用户 ID 分离缓存）和跨服务共享缓存（如 Redis 后端）需要额外配置，这些地方一旦设错，表现往往是“看起来缓存了，但数据总是旧的”或者“不同用户看到彼此的缓存结果”。
