为何ActionResult<T>不接受实现IActionResult接口的T实例？

首先看ActionResult<TValue>的定义：

public sealed class ActionResult<TValue> : IConvertToActionResult
{...}

它的构造函数做了严格检查：

public ActionResult(TValue value)
{
    if (typeof(IActionResult).IsAssignableFrom(typeof(TValue)))
    {
        var error = Resources.FormatInvalidTypeTForActionResultOfT(typeof(TValue), "ActionResult<T>");
        throw new ArgumentException(error);
    }

    Value = value;
}

问题：为何TValue实现IActionResult接口会成为问题？我能理解ActionResult的功能，但无法理解该检查及抛出异常的原因。

核心原因拆解 #

• 消除语义歧义：ActionResult<T>的定位是业务数据的包装器，它的作用是让控制器既能返回业务数据（框架自动序列化后返回），也能灵活切换返回标准HTTP动作结果（比如NotFound、Redirect）。如果TValue本身是IActionResult实现类，就会出现逻辑矛盾：你到底是要执行这个动作结果（返回404/跳转），还是要把这个动作结果对象当作业务数据返回给前端？框架无法判断你的真实意图，必然导致执行结果偏离预期。

• 简化框架处理逻辑：ASP.NET Core在处理Action返回值时，会根据类型分支处理。如果允许TValue是IActionResult，框架需要额外增加一层判断：是直接执行这个IActionResult，还是把它当作普通值进行包装处理？这会大幅增加底层逻辑的复杂度，还容易引入难以排查的bug。

• 明确职责边界：ActionResult<T>是“数据+动作结果”的中间适配层，而IActionResult的实现类（比如NotFoundResult、FileResult）是直接对应HTTP响应的动作指令。禁止TValue实现IActionResult，就是强制让两者职责分离，让代码意图更清晰，避免开发者写出模棱两可的代码。

举个直观的反例：如果允许这种情况，你写return new ActionResult<NotFoundResult>(new NotFoundResult());，框架到底是直接返回404状态码，还是把NotFoundResult对象序列化成JSON返回给前端？这种模糊性完全没有必要，所以干脆在构造阶段就直接禁止。

内容的提问来源于stack exchange，提问作者GrumpyRodriguez