resultfilter 仅对成功执行的 actionresult 生效，不处理异常、重定向及已写入响应流的情况，且需在 onresultexecuting 中安全替换 context.result。
ResultFilter 不是“在 Action 返回后改响应体”的万能钩子，它只对成功执行的 ActionResult 生效，且无法修改已写入的响应流（比如 HttpContext.Response 已开始写入后调用 context.Result = new JsonResult(...) 会抛异常）。
ResultFilter 什么时候根本不会触发
常见错误现象：OnResultExecuting 和 OnResultExecuted 完全没进断点，但 Action 正常返回了 JSON；或者过滤器里加了日志却看不到输出。
- Action 抛出了未捕获异常 → 请求直接走
IExceptionFilter或中间件，跳过所有 ResultFilter 生命周期 - Action 返回了
return Content("hello")，但你在过滤器里试图读context.Result.Value→ContentResult没有Value属性，会NullReferenceException - Action 中提前设置了
context.Result = new EmptyResult()或return NotFound()，而你的 ResultFilter 又在OnResultExecuting里做了非空判断后直接 return → 后续逻辑被跳过，但你以为“应该走了” - 注册方式错误：用了
[ServiceFilter(typeof(MyResultFilter))]但MyResultFilter没在 DI 容器注册 → 静默失效，连构造函数都不会调用
如何安全地在 ResultFilter 中修改响应内容
核心原则：只在 OnResultExecuting 中替换 context.Result，且必须确保新 ActionResult 能正确序列化、不依赖已被释放的上下文资源。
- 不要尝试在
OnResultExecuted中改context.Result→ 此时响应头可能已发送，改了也无效，还会触发InvalidOperationException: Headers are read-only - 若原结果是
ObjectResult（如Ok(model)），可安全提取model并包装：context.Result = new OkObjectResult(new { Data = model, Timestamp = DateTime.UtcNow }) - 若原结果是
FileStreamResult或PhysicalFileResult，别碰context.Result→ 它们走的是底层文件流管道，强行替换会导致 500 或空响应 - 想统一加响应头？用
context.HttpContext.Response.Headers.Append("X-Processed", "true")，这个在OnResultExecuting或OnResultExecuted都安全
ResultFilter 和 ActionFilter 的关键行为差异
很多人把两者混用，结果发现日志顺序错乱、响应被意外覆盖——本质是生命周期和作用阶段不同。
-
ActionFilter.OnActionExecuted在 Action 方法**刚返回**、但IActionResult还没执行前触发；此时context.Result是 Action 返回的对象，但尚未渲染 -
ResultFilter.OnResultExecuting在IActionResult.ExecuteAsync()**即将开始执行前**触发；此时你看到的context.Result就是最终要执行的那个实例 - 同一个请求中，
ActionFilter.OnActionExecuted一定比ResultFilter.OnResultExecuting先执行 —— 即使你给它们设了相同Order - 如果 Action 返回
return View()，ResultFilter看到的是ViewResult，但你不能在其中改Model字段（它是只读的），只能整体替换context.Result
全局注册 ResultFilter 时的 DI 生命周期陷阱
全局注册的 ResultFilter 默认是 singleton，但它的方法里常需要 IConfiguration、ILogger 这类 scoped 服务。
- 别在构造函数里注入
IHttpContextAccessor或ILogger<myresultfilter></myresultfilter>→ 启动时报Cannot resolve scoped service from root provider - 正确做法：在
OnResultExecuting中按需解析：var logger = context.HttpContext.RequestServices.GetRequiredService<ilogger>>();</ilogger> - 如果真要用
ILogger，推荐注册为 singleton：services.AddSingleton<ilogger>>(sp => sp.GetRequiredService<iloggerfactory>().CreateLogger<myresultfilter>());</myresultfilter></iloggerfactory></ilogger>，但注意日志作用域（Scope）会丢失 - 想读取当前用户信息？别用
context.HttpContext.User（它在 ResultFilter 阶段仍可用），但别试图从它里面取ClaimsPrincipal以外的业务属性（比如User.FindFirst("TenantId")?.Value可以，User.GetTenantConfig()这种扩展方法大概率为空）
最易被忽略的一点：ResultFilter 对 RedirectToActionResult、LocalRedirectResult 这类跳转结果完全无感——它不处理 HTTP 302 响应体，只管“渲染动作”。你要拦截重定向，得用中间件或 AuthorizationFilter。
