使用object作为.NET控制器Action返回类型是否存在弊端？

你当前场景里，虽然序列化后客户端能正常解析，但用object作为返回类型确实存在不少隐性问题，具体如下：

• 失去编译时类型校验
  如果不小心返回了错误类型（比如直接返回dto而非包装后的结果类），编译器不会报错，只有运行时才会暴露问题，徒增调试成本。比如误写return dto;，客户端拿到的数据结构会完全不符合预期，却没法提前发现。

• API文档生成失效
  ASP.NET Core的Swagger/OpenAPI这类文档工具，依赖方法返回类型自动生成响应结构。返回object的话，文档里只会显示模糊的object类型，没法体现通用结果类和内部DTO的具体字段，前端开发没法直接从文档获取接口响应信息，协作效率大打折扣。

• 框架处理的额外开销
  即便你认为没有装箱拆箱问题，ASP.NET Core处理object返回值时，会额外做类型推断和序列化适配。相比返回具体泛型结果类型（比如Task<Result<TestDTO>>），框架需要更多反射操作确定实际类型，高并发场景下这部分开销会被放大。

• 代码可读性与维护性下降
  其他开发者看代码时，没法从方法签名直接知道返回的具体结构，必须进入方法内部查看，增加理解成本。后续如果通用结果类结构调整，返回object的方法无法通过编译检查快速定位受影响的位置。

• 序列化异常排查难度提升
  当下序列化正常，但如果后续通用结果类引入了默认序列化器无法处理的类型（比如非公开字段、循环引用），返回object会让错误更难排查——编译器无法提前感知类型兼容性，问题只会在运行时爆发。

替代方案建议 #

定义一个泛型通用结果类：

public class ApiResult<T>
{
    public T Data { get; set; }
    public bool Success { get; set; }
    public string Message { get; set; }
}

方法直接返回具体泛型类型：

public async Task<ApiResult<TestDTO>> GetDTO([FromBody]string name)
{
    var dto = new TestDTO { 
        Number = 123,
        Name = name,
        Data = new List<string>() { "aaa", "bbb", "ccc" }
    };

    return new ApiResult<TestDTO> { Data = dto, Success = true, Message = "* result mesage *" };
}

这样既保留了通用包装的需求，又避免了object返回的各种问题，同时能让API文档、编译检查正常工作。

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