.NET多类型用户如何通过单一API路由实现登录并返回不同用户对象

单接口返回不同类型用户的可行性 #

完全可以实现，以下是两种常用实现方式：

1. 利用多态特性，直接将接口返回值声明为 ActionResult<User>
   因为 Customer 和 Vendor 都继承自 User，你可以在方法内部根据业务逻辑直接返回对应子类的实例。如果用ASP.NET Core默认的System.Text.Json序列化，只需要给抽象基类加上多态序列化配置即可：

[JsonDerivedType(typeof(Customer), typeDiscriminator: "Customer")]
[JsonDerivedType(typeof(Vendor), typeDiscriminator: "Vendor")]
public abstract class User
{
    public Guid Id { get; set; }
    public string PhoneNumber { get; set; }
    public string Password { get; set; }
}

序列化后的返回结果会自动带上类型标识字段，前端可以直接根据这个字段判断当前登录用户的类型，同时子类的所有属性都会正常输出。
2. 若不想引入类型鉴别器，也可以将返回值声明为 ActionResult<object>，序列化时会自动输出所有属性，不过没有强类型约束，不推荐生产环境使用。

这种单接口方案仅适合两类用户的登录逻辑高度一致、后续不会出现大量差异化逻辑的场景。

三种架构方案的优劣对比与选择 #

如果后续两类用户的登录逻辑大概率会有差异化迭代（比如商户登录需要额外校验经营资质状态、普通用户登录需要校验账号封禁状态等），更推荐拆分接口，三个方案的优先级如下：

最优选择：两个独立路由 /api/customer/login 和 /api/vendor/login #

符合RESTful接口设计的资源导向原则，两个接口职责完全独立，后续业务逻辑变化时可以分别迭代，不会互相耦合，前端调用时语义清晰，不会出现传错用户类型的低级错误，是生产环境最通用的选择。

次优选择：两个归属用户模块的路由 /api/user/customer/login 和 /api/user/vendor/login #

本质和第一种方案没有逻辑差异，只是路由多了一层user前缀，适合项目有统一规范要求所有用户相关接口必须归类到/api/user模块下的场景，没有明显缺陷，只是路由层级更长。

不推荐选择：单一路由携带用户类型枚举 #

仅适合极小且不会有后续迭代的临时项目。缺点非常明显：接口内部需要维护大量分支判断逻辑，违反单一职责原则，后续迭代很容易出现兼容问题，而且如果请求参数传错用户类型，会导致返回结果不符合预期，排查成本很高。

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