嘿，这个问题问到点子上了——我在不同项目里既单独用过Razor Pages，也混用过它和MVC，结合自己的实践和社区讨论，给你梳理一下：

一、除了页面简洁，选择Razor Pages的其他理由（含性能） #

Steve Smith提到的文件数量少确实是直观优势，但还有不少更实际的考量：

• 更贴合页面优先的开发模式：如果你的项目是偏展示型的（比如CMS、企业官网、简单电商前台），Razor Pages的页面级关注点分离更自然——页面的逻辑（数据加载、表单提交）和视图绑定在一起，不用在控制器和视图文件夹之间来回切换，思维连贯性更强。
• 性能略胜一筹：从官方基准测试和实际项目压测来看，Razor Pages的路由匹配效率比MVC更高。因为它的路由系统直接映射到物理文件，不需要额外解析控制器名称、动作名称这一层，在高并发场景下，这一点点差异会被放大，减少服务器的路由解析开销。
• 更省心的默认安全配置：Razor Pages默认就启用了Anti-Forgery Token验证，不用像MVC那样手动在每个POST动作上加[ValidateAntiForgeryToken]属性，降低了新手遗漏安全配置的风险。
• 更清晰的生命周期：OnGet、OnPost、OnPut这些方法直接对应HTTP动词，新手不用纠结“动作该怎么命名”“哪个动作对应哪个请求”，学习曲线更平缓。

二、能不能同时混用Razor Pages和Controllers/Views？ #

完全可以！ASP.NET Core从设计之初就支持两者共存，甚至还能和Web API一起用。我之前做过一个项目：

• 前台用户界面用Razor Pages快速搭建，因为页面逻辑简单，开发速度快；
• 后台管理系统用MVC的Controllers/Views，因为涉及复杂的权限控制、多步骤业务流程，用控制器拆分逻辑更清晰；
  两者共享同一个依赖注入容器、中间件和数据库上下文，没有任何冲突。
  唯一需要注意的是路由规划：Razor Pages默认路由是/{page}，MVC是/{controller}/{action}，只要提前规划好路径（比如后台路径统一用/admin/{controller}/{action}），就不会出现路由冲突的问题。

三、资深开发者视角的优缺点总结 #

优点 #

• 开发效率拉满：简单页面不用创建单独的控制器类，一个.cshtml加对应的.cshtml.cs就搞定，文件结构直观，新人接手快。
• 低学习成本：对刚接触ASP.NET Core的开发者友好，不用先理解控制器、动作、路由模板这些复杂概念，写个页面就能跑起来。
• 页面逻辑封装性好：单个页面的所有逻辑都在页面模型里，维护的时候不用跳多个文件，找问题更快。

缺点 #

• 复杂场景下易臃肿：如果一个页面涉及多种业务逻辑（比如既有表单提交，又有多条件数据筛选，还有文件上传），页面模型会变得很长，代码可读性下降，不如MVC把逻辑拆分到不同的控制器动作清晰。
• 自定义路由灵活性不足：虽然可以用@page指令配置路由，但复杂的路由规则（比如多参数约束、动态路由）还是MVC的[Route]属性更灵活。
• 大型项目扩展性弱：当项目页面数量过百，按文件夹划分页面的结构会显得杂乱，不如MVC按功能模块划分控制器的方式更容易管理和扩展。

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