ASP.NET Core 8 中 Output Caching 必须显式启用：需在 Program.cs 中调用 AddOutputCache() 注册服务并使用 UseOutputCache() 注册中间件，否则缓存完全不生效且无提示；[EnableOutputCaching] 比 [ResponseCache] 更强大，支持自定义键、查询参数区分等高级功能。
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 后端）需要额外配置，这些地方一旦设错，表现往往是“看起来缓存了，但数据总是旧的”或者“不同用户看到彼此的缓存结果”。
