ASP.NET Core 5用Core Identity时混用MVC与Razor Pages是否为合理实践？

是否存在必须避免混用的明确原因 #

不存在技术层面的硬性限制要求必须避免二者混用。ASP.NET Core底层使用统一的端点路由体系，MVC控制器/视图和Razor Pages的运行时管道完全兼容，同时启用两种开发模式不会出现运行时冲突、功能异常等问题。
唯一可能需要规避混用的场景是团队已明确制定了统一技术栈的编码规范，混用会提升团队协作的维护成本，但这属于项目管理层面的要求，并非框架层面的强制限制。 #

混用属于良好还是不良开发实践 #

没有绝对的好坏判定，需要结合项目实际需求判断：

• 若你的身份认证模块仅需要使用官方Identity的默认功能，后续几乎不需要做自定义扩展，直接引入Identity Razor Pages是投入产出比最高的方案，这种情况下混用属于完全可接受的开发实践，不需要为了追求所谓的「单一开发模式」额外投入时间重写登录、注册、找回密码等通用功能。
• 若你的项目存在大量自定义身份认证逻辑（比如多租户适配、自定义权限校验、企业SSO集成等），后续需要频繁迭代修改认证模块代码，那么保持全MVC的单一技术栈更利于长期维护，这种情况下避免混用是更合理的选择。

业内专业角度的实际评价 #

业内的普遍共识是「技术选型优先服务于业务需求，无需为了追求技术栈纯粹性牺牲开发效率」：

• 中小规模项目、对交付时效要求高的项目，直接使用Identity Razor Pages与现有MVC代码混用是非常普遍的做法，绝大多数.NET开发者都有相关的项目实践经验。
• 大型企业级项目、团队规模在5人以上的协作项目，通常会要求统一技术栈，避免不同开发人员因技术栈熟悉度差异产出风格差异过大的代码，这类场景下会更倾向于使用全MVC或者全Razor Pages的单一开发模式。

补充实践建议 #

如果选择混用方案，可以将Identity相关的Razor Pages统一放在单独的Identity Area中，和MVC业务代码做物理隔离，降低后期维护成本。如果选择自主实现MVC版本的身份认证，直接调用SignInManager、UserManager、RoleManager的公共API属于官方推荐的使用方式，完全符合框架设计规范，不存在任何兼容性风险。

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