为何提前写入HttpContext.Response后MVC控制器响应未追加

endpoints.MapControllers() 本身不存在「检查Response已有内容就中止写入」的逻辑，内容丢失的核心原因是MVC框架内置的Action结果执行器的前置校验规则，两种代码场景的差异来自MVC管线和最小API的响应写入逻辑区别：

• 你用endpoints.MapGet注册的是最小API端点，委托内直接调用Response.WriteAsync写入响应，这个方法本身不会做响应状态校验，只要响应流未关闭就会持续追加内容，所以可以看到两段内容拼接的结果。
• MapControllers挂载的是MVC控制器端点，Action方法执行完成后，会通过对应的IActionResultExecutor实现类把返回结果写入响应，所有内置的结果执行器在正式写入前，都会先检查HttpContext.Response.HasStarted属性：如果该属性为true（代表响应头已经发送到客户端、响应流已经启动写入），执行器会直接返回，不再执行任何响应写入操作，也不会抛出异常。你在自定义中间件里提前调用Response.WriteAsync的操作，会直接触发响应启动，将HasStarted置为true，因此后续MVC即使执行了Action方法，结果也无法写入响应流，这就是你断点能命中Action但看不到对应输出的原因。

响应启动状态的校验逻辑不在MapControllers的端点注册代码中，而是分布在各个内置的Action结果执行器里：

• 通用对象结果执行器ObjectResultExecutor的ExecuteAsync方法开头就包含如下校验逻辑：

public virtual Task ExecuteAsync(ActionContext context, ObjectResult result)
{
    // 省略参数合法性校验逻辑
    var response = context.HttpContext.Response;
    // 响应已启动则直接跳过所有写入逻辑
    if (response.HasStarted)
    {
        return Task.CompletedTask;
    }
    // 省略后续内容协商、序列化写入响应的逻辑
}

• 其余内置结果执行器，包括ContentResultExecutor、JsonResultExecutor、ViewResultExecutor、RedirectResultExecutor等，都在执行逻辑开头加入了相同的Response.HasStarted判断。

注意：不建议在后续管道组件执行前提前写入响应流，该操作不仅会导致后续组件的响应内容丢失，还会在后续逻辑尝试修改响应状态码、响应头时抛出异常。

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