返回其他内容类型：IResult与Results.Text的对比探讨

问题背景 #

昨日我提出了关于通用返回不同内容类型的问题，得到了使用通配符路由的提示。等待回复期间，我尝试了Results.Text()的扩展方法，结合通配符路由实现了如下示例：

针对固定HTML类型的路由：

app.MapGet("/html/{*rest}", () => {
    (string content, int statusCode) = GetHtmlResults(rest);
    return Results.Text(content:content, contentType:"text/html", contentEncoding:Encoding.UTF8, statusCode: statusCode);
});

支持通用内容类型的路由：

app.MapGet("/generic/{*rest}", (HttpContext httpContext) => {
    (string content, int statusCode, string contentType) = GetGenericResults(httpContext,rest);
    return Results.Text(content:content, contentType:contentType, contentEncoding:Encoding.UTF8, statusCode: statusCode);
});

这种方式比继承IResult的类更直接简洁。请问IResult是否只是更结构化的同类实现？二者的优缺点分别是什么？

核心结论 #

Results.Text()是.NET框架封装好的IResult实现之一，自定义IResult类则是对响应逻辑的结构化扩展——二者本质都是实现IResult接口来处理HTTP响应，但适用场景和特性差异明显。

一、使用Results.Text()的优缺点 #

优点

• 简洁高效：无需额外定义类，直接通过静态方法快速构建文本类型响应，代码量少，适配简单场景。
• 内置优化：框架已处理编码、Content-Type、状态码等细节，避免重复造轮子，降低出错概率。
• 可读性强：方法名和参数语义明确，其他开发者能快速理解响应逻辑。

缺点

• 灵活性有限：仅适用于文本类响应（如HTML、纯文本、XML字符串等），无法处理二进制流、文件下载等复杂响应场景。
• 复用性弱：如果多个路由需要相同的响应逻辑（比如统一的错误格式、自定义头信息），只能重复调用方法，无法封装复用。
• 扩展难度大：无法直接添加自定义响应头、Cookie等额外操作，需结合HttpContext单独处理，代码冗余。

二、自定义IResult类的优缺点 #

优点

• 高度灵活：可完全自定义响应逻辑，支持二进制内容、自定义头、Cookie、状态码组合等任意HTTP响应需求。
• 复用性强：将通用响应逻辑封装成独立类，多个路由可直接复用，减少代码重复。
• 结构化管理：复杂响应逻辑（如多格式内容协商、统一异常处理）可通过类的继承、组合组织，代码结构更清晰。

缺点

• 代码量增加：需手动实现IResult接口的ExecuteAsync方法，编写额外类定义，初期开发成本更高。
• 需关注细节：要自行处理编码、Content-Type、状态码、响应流写入等细节，容易出现疏漏（比如编码错误、响应头设置不当）。
• 学习成本：需要理解IResult接口的执行机制，对.NET HTTP响应管道有一定了解才能正确实现。

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