尧图网页设计 
ASP.NET Core Razor Pages 实战指南以页面为中心的服务端渲染应用构建与选型【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills导读Razor Pages 是 ASP.NET Core 内置的页面级 Web 应用模型特别适合请求天然映射到页面 表单 页面级处理器的场景是内部工具、CRUD 应用、账号流程account flows与后台管理界面admin surfaces的强默认选择。本指南基于本仓库 aspnet-core 技能中 ui-razor-pages.md 参考文档为核心骨架结合仓库内 stack-selection.md、program-and-pipeline.md、security-and-identity.md、ui-mvc.md 等关联参考作深度佐证系统讲解何时选择 Razor Pages、如何启用与组织应用、路由模型与 PageModel 处理器、表单绑定与验证、以及其关键限制per-handler 授权与应对策略。读完本文你将具备用 Razor Pages 构建规范、可维护、可测试的页面级服务端渲染应用的完整实战能力并能依据项目形态在 Razor Pages、MVC、Blazor 之间做出有依据的架构决策。一、何时选择 Razor Pages页面中心应用的默认模型1.1 核心判断标准根据 ui-razor-pages.md 的明确指引当请求天然映射到页面、表单与页面级处理器时应优先选择 Razor Pages。这是一个强默认strong default尤其适用于内部工具internal tools以页面为基本操作单元的运维、配置、管理后台CRUD 应用对资源进行增删改查的典型业务系统账号流程account flows登录、注册、资料编辑、密码重置等表单驱动流程后台管理界面admin surfaces管理仪表盘、数据维护界面1.2 与其它应用模型的快速对比仓库 stack-selection.md 中的应用模型矩阵给出了清晰的选型边界模型优先场景需要警惕的点典型起点模板Razor Pages页面导向的 CRUD、表单、仪表盘与业务线应用授权无法精确到单个页面 handler需要 handler 级控制时改用 MVCdotnet new webappMVC需要清晰控制器/视图分离、过滤器与 action 模式的大型服务端渲染应用对简单页面流程而言仪式感过重dotnet new mvcBlazor Web App用 .NET 组件模型构建全栈 UISSR 加可选交互交互式服务端渲染需要实时连接WebAssembly 增加载荷dotnet new blazorMinimal APIs聚焦的 HTTP API、内部服务、轻量后端业务逻辑或元数据膨胀后 route handler 难管理dotnet new webapi或dotnet new web选型速记Fast HeuristicsUI 本身应作为 .NET 组件模型 → 选 Blazor Web App应用大部分是页面与表单导向→ 选 Razor Pages设计核心是 action、视图、过滤器与控制器约定 → 选 MVC已有代码库请保留现有应用模型除非模型错配已经造成实际复杂度。1.3 Razor Pages 的良好匹配场景ui-razor-pages.md 明确列出以下典型契合点表单密集的工作流form-heavy workflowsRazor Pages 的页面级 handler 模型绑定 Tag Helpers 让表单处理代码量显著低于手工解析仪表盘与后台办公应用dashboards and back-office applications带服务端校验的简单内容simple content with server-side validation页面是主要导航单位的应用这些场景的共同点是一个 URL 对应一个页面、一组页面级动作GET/POST/命名 handler不需要跨 action 共享的控制器级行为因此 Razor Pages 的轻量模型恰好命中。二、核心形态启用、端点化与代码组织2.1 启用 Razor Pages在现代化宿主模型WebApplicationBuilder/WebApplication见 program-and-pipeline.md下启用 Razor Pages 只需两行核心代码var builder WebApplication.CreateBuilder(args); // 1. 注册 Razor Pages 相关服务页面、模型绑定、Tag Helpers、防伪等 builder.Services.AddRazorPages(); var app builder.Build(); // 2. 将 Razor Pages 端点映射到路由表 app.MapRazorPages(); app.Run();对应的脚手架命令是仓库 stack-selection.md 中列出的dotnet new webapp.NET 10 SDK 模板短名可通过dotnet new list验证当前环境模板名。2.2page指令把 .cshtml 变成端点使用page指令可以将一个.cshtml文件变成 HTTP 端点。当一个页面超过平凡trivial规模时请求逻辑应放在配对的PageModel类中而不是堆在 Razor 视图代码里。这是保持页面可测试性、可维护性的关键组织原则。一个最小页面形态Pages/Index.cshtmlpage model IndexModel h1Model.Message/h1对应 PageModelPages/Index.cshtml.cspublic class IndexModel : PageModel { public string Message { get; set; } string.Empty; public void OnGet() { Message Hello from Razor Pages!; } }2.3 与 MVC 的核心形态差异对比仓库 ui-mvc.mdMVC 需要builder.Services.AddControllersWithViews();与app.MapControllerRoute(...)通过控制器 action 处理请求而 Razor Pages没有控制器层请求直接由页面文件 PageModel 承接。这正是页面即端点与控制器即端点的本质区别。三、路由模型文件系统即 URL 结构ui-razor-pages.md 对路由模型给出最简明的三条规则默认情况下文件系统位置决定路由Pages/Index.cshtml映射到/Pages/Store/Index.cshtml映射到/Store由此衍生出的工程准则文件夹结构必须有意义因为它会成为 URL 结构。例如Pages/ ├── Index.cshtml → / ├── Store/ │ ├── Index.cshtml → /Store │ ├── Products.cshtml → /Store/Products │ └── Orders/ │ ├── Index.cshtml → /Store/Orders │ └── Detail.cshtml → /Store/Orders/Detail这条规则的直接推论规划新页面时先想清楚 URL 与导航层级再决定文件放在哪个文件夹不要用无意义的扁平目录堆页面否则 URL 结构会失去可读性需要更灵活的路由时page指令支持路由模板参数如page {id:int}但默认文件系统路由已覆盖绝大多数页面场景。四、PageModel 处理器指南OnGet / OnPost 与命名 handler4.1 处理器方法PageModel 通过约定命名的方法处理不同 HTTP 谓词OnGet→ 处理 GET 请求页面首次加载、链接跳转OnPost→ 处理 POST 请求表单提交命名 handlernamed handlers→ 同一页面处理多个语义不同的操作例如OnPostDelete、OnPostApprove在表单/链接中通过asp-page-handler或handler路由值指定4.2 表单处理绑定属性 模型验证ui-razor-pages.md 明确要求使用可绑定属性bindable properties和模型验证处理表单使用 Tag Helpers 和模型绑定而不是手工解析请求。典型表单页Pages/Products/Create.cshtml.cspublic class CreateModel : PageModel { private readonly IProductService _service; public CreateModel(IProductService service) { _service service; } [BindProperty] public ProductInput Input { get; set; } new(); public void OnGet() { // 初始化页面需要的下拉选项等 } public async TaskIActionResult OnPostAsync() { if (!ModelState.IsValid) { return Page(); // 校验失败重新渲染当前页并回显错误 } await _service.CreateAsync(Input); return RedirectToPage(./Index); // POST-Redirect-GET } }配合 Tag Helpers 的表单视图Pages/Products/Create.cshtmlpage model CreateModel form methodpost div asp-validation-summaryAll/div div label asp-forInput.Name/label input asp-forInput.Name / span asp-validation-forInput.Name/span /div button typesubmit创建/button /form要点拆解[BindProperty]让Input自动参与模型绑定无需手写Request.Form[...]asp-for、asp-validation-for、asp-validation-summary等 Tag Helpers 自动生成 name/id/校验消息规避手工拼接 HTML 的低级错误校验失败返回Page()重新渲染并展示ModelState中的错误成功操作采用POST-Redirect-GET模式RedirectToPage避免刷新重复提交——这与仓库 ui-mvc.md 对 MVC 表单提交的要求完全一致。4.3 让 PageModel 保持薄ui-razor-pages.md 给出的四条 PageModel 铁律用OnGet、OnPost与命名 handler 处理请求用可绑定属性与模型验证处理表单保持页面模型薄thin把业务逻辑移入注入的服务injected services用 Tag Helpers 与模型绑定而非手工解析请求这与仓库 program-and-pipeline.md 的架构默认一致把业务逻辑放在服务中而不是控制器、页面模型或路由 handler 中并默认使用构造函数注入constructor injection服务生命周期按 singleton无状态/共享基础设施、scoped请求级工作如DbContext、transient轻量无状态三类理性选择。4.4 页面级授权与防伪从仓库 security-and-identity.md 的边界防护原则看Razor Pages 应用应在PageModel 层施加[Authorize]可作用于页面模型类并通过RequireAuthorization()施加于端点同时cookie 交互式应用与表单提交必须启用防伪antiforgery保护——Razor Pages 的formTag Helper 会自动生成并校验防伪令牌。需要强调的是Razor Pages 的授权以页面为粒度这一特点正是下文第五节要展开的关键限制。五、关键限制与应对per-handler 授权5.1 限制本身ui-razor-pages.md 明确指出不要依赖 Razor Pages 的 per-handler 授权。当同一逻辑面上的不同 handler 需要不同授权行为时微软明确建议改用 MVC 控制器。原因在于Razor Pages 的授权粒度为页面PageModel级别[Authorize]作用于整个页面模型类而同一页面上的OnGet/OnPost/命名 handler 无法各自声明独立的授权策略。若一个页面里查看允许匿名、删除仅限管理员Razor Pages 的授权模型无法干净表达这种差异。5.2 官方建议的两种应对ui-razor-pages.md 给出两种首选应对把 handler 拆分到独立页面split the handlers into separate pages将不同授权语义的操作拆成不同页面每个页面拥有独立的[Authorize]粒度问题随即消失把该表面迁移到 MVCmove the surface to MVC当 action 级授权更契合业务时将这块逻辑面改为 MVC 控制器利用 action 级[Authorize]与授权过滤器获得精确控制。仓库 ui-mvc.md 在选择 MVC 而非 Razor Pages一节给出了同源结论当以下任一条件成立时优先 MVC——多个相关 action 共享控制器级行为handler 级授权或 action 过滤器很重要URL 与 action 设计比页面文件路由更自然5.3 其它隐含注意点不要在页面逻辑里把所有决策硬编码为角色判断仓库 security-and-identity.md 建议使用策略policies与声明claims做授权遇到上述限制时先评估拆分页面是否更简单再考虑引入 MVCSKILL.md 的默认假设也提醒尊重现有应用模型没有明确理由不要把 Razor Pages 重写为 MVC。六、组织规范文件夹、分部视图、区域与共享布局ui-razor-pages.md 最后给出四条组织层面的指导把相关页面分组到文件夹Group related pages into folders如上面第三节所示文件夹即 URL合理的分组同时优化了 URL 与代码导航对重复片段使用分部视图Use partial views for repeated fragments公共表单区块、分页控件、状态提示等抽成_partial避免复制粘贴仅在应用存在清晰有界分区时使用区域Use areas only when the application has clear bounded sections例如 Admin、BackOffice 这样的大型独立分区这与仓库 program-and-pipeline.md 中仅在应用大到足以受益于有界分区时使用 Areas的表述一致——不要为了用 Areas 而用 Areas集中维护共享布局与页面约定Keep shared layout and page conventions centralized_Layout.cshtml、_ViewImports.cshtml全局using/Tag Helper 声明、_ViewStart.cshtml集中管理保持全站视觉与结构一致。对较大项目可结合仓库 program-and-pipeline.md 的架构默认优先垂直切片/特性文件夹避免把代码堆进弱边界的巨型 Controllers/Services/Repositories 桶。七、与整体技能流程的衔接在仓库的 aspnet-core 技能工作流中Razor Pages 作为且仅作为一个主应用模型参考被加载references/ui-razor-pages.md与 Blazor、MVC、Minimal/控制器 API 并列互斥跨切面需求再按需追加 security-and-identity.md、data-state-and-services.md、testing-performance-and-operations.md 等参考。_sections.md 给出的推荐路径是新建应用走stack-selection→program-and-pipeline→ 一个主应用模型参考 →security-and-identity→testing-performance-and-operations。也就是说Razor Pages 决策通常发生在选型阶段stack-selection.md随后按 program-and-pipeline.md 的启动形态与中间件顺序组装应用。实操中可遵循的完整落地清单dotnet new webapp创建 Razor Pages 项目.NET 10 SDK 下默认模板在Program.cs中builder.Services.AddRazorPages();app.MapRazorPages();按 URL 结构规划Pages/文件夹树简单页面用page 内联 Razor复杂页面把逻辑放入配对的PageModel表单一律走[BindProperty] Tag Helpers 模型验证 POST-Redirect-GET业务逻辑下沉到注入的服务DI 合适的生命周期需要页面级安全时在 PageModel/端点上施加[Authorize]启用防伪保护遇到同一页面不同 handler 需不同授权时拆分页面或迁移到 MVC相关页面分组、重复片段抽分部视图、共享布局集中维护。结语Razor Pages 是 ASP.NET Core 中页面即端点的服务端渲染模型在表单密集的内部工具、CRUD、账号流程与后台管理场景中拥有最低的仪式成本与最清晰的表达力。它的默认文件系统路由让 URL 结构可预测PageModel 处理器让每个页面的请求逻辑集中且可测其最重要的边界在于授权粒度——当业务需要 per-handler 级授权时应果断拆分页面或切换到 MVC。结合本仓库 aspnet-core 技能提供的选型矩阵、启动流水线、安全与组织规范等配套参考你可以在具体项目中快速判断是否该用 Razor Pages并把它用对、用规范。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 ASP.NET Core Razor Pages 实战指南：以页面为中心的服务端渲染应用构建与选型
ASP.NET Core Razor Pages 实战指南以页面为中心的服务端渲染应用构建与选型【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills导读Razor Pages 是 ASP.NET Core 内置的页面级 Web 应用模型特别适合请求天然映射到页面 表单 页面级处理器的场景是内部工具、CRUD 应用、账号流程account flows与后台管理界面admin surfaces的强默认选择。本指南基于本仓库 aspnet-core 技能中 ui-razor-pages.md 参考文档为核心骨架结合仓库内 stack-selection.md、program-and-pipeline.md、security-and-identity.md、ui-mvc.md 等关联参考作深度佐证系统讲解何时选择 Razor Pages、如何启用与组织应用、路由模型与 PageModel 处理器、表单绑定与验证、以及其关键限制per-handler 授权与应对策略。读完本文你将具备用 Razor Pages 构建规范、可维护、可测试的页面级服务端渲染应用的完整实战能力并能依据项目形态在 Razor Pages、MVC、Blazor 之间做出有依据的架构决策。一、何时选择 Razor Pages页面中心应用的默认模型1.1 核心判断标准根据 ui-razor-pages.md 的明确指引当请求天然映射到页面、表单与页面级处理器时应优先选择 Razor Pages。这是一个强默认strong default尤其适用于内部工具internal tools以页面为基本操作单元的运维、配置、管理后台CRUD 应用对资源进行增删改查的典型业务系统账号流程account flows登录、注册、资料编辑、密码重置等表单驱动流程后台管理界面admin surfaces管理仪表盘、数据维护界面1.2 与其它应用模型的快速对比仓库 stack-selection.md 中的应用模型矩阵给出了清晰的选型边界模型优先场景需要警惕的点典型起点模板Razor Pages页面导向的 CRUD、表单、仪表盘与业务线应用授权无法精确到单个页面 handler需要 handler 级控制时改用 MVCdotnet new webappMVC需要清晰控制器/视图分离、过滤器与 action 模式的大型服务端渲染应用对简单页面流程而言仪式感过重dotnet new mvcBlazor Web App用 .NET 组件模型构建全栈 UISSR 加可选交互交互式服务端渲染需要实时连接WebAssembly 增加载荷dotnet new blazorMinimal APIs聚焦的 HTTP API、内部服务、轻量后端业务逻辑或元数据膨胀后 route handler 难管理dotnet new webapi或dotnet new web选型速记Fast HeuristicsUI 本身应作为 .NET 组件模型 → 选 Blazor Web App应用大部分是页面与表单导向→ 选 Razor Pages设计核心是 action、视图、过滤器与控制器约定 → 选 MVC已有代码库请保留现有应用模型除非模型错配已经造成实际复杂度。1.3 Razor Pages 的良好匹配场景ui-razor-pages.md 明确列出以下典型契合点表单密集的工作流form-heavy workflowsRazor Pages 的页面级 handler 模型绑定 Tag Helpers 让表单处理代码量显著低于手工解析仪表盘与后台办公应用dashboards and back-office applications带服务端校验的简单内容simple content with server-side validation页面是主要导航单位的应用这些场景的共同点是一个 URL 对应一个页面、一组页面级动作GET/POST/命名 handler不需要跨 action 共享的控制器级行为因此 Razor Pages 的轻量模型恰好命中。二、核心形态启用、端点化与代码组织2.1 启用 Razor Pages在现代化宿主模型WebApplicationBuilder/WebApplication见 program-and-pipeline.md下启用 Razor Pages 只需两行核心代码var builder WebApplication.CreateBuilder(args); // 1. 注册 Razor Pages 相关服务页面、模型绑定、Tag Helpers、防伪等 builder.Services.AddRazorPages(); var app builder.Build(); // 2. 将 Razor Pages 端点映射到路由表 app.MapRazorPages(); app.Run();对应的脚手架命令是仓库 stack-selection.md 中列出的dotnet new webapp.NET 10 SDK 模板短名可通过dotnet new list验证当前环境模板名。2.2page指令把 .cshtml 变成端点使用page指令可以将一个.cshtml文件变成 HTTP 端点。当一个页面超过平凡trivial规模时请求逻辑应放在配对的PageModel类中而不是堆在 Razor 视图代码里。这是保持页面可测试性、可维护性的关键组织原则。一个最小页面形态Pages/Index.cshtmlpage model IndexModel h1Model.Message/h1对应 PageModelPages/Index.cshtml.cspublic class IndexModel : PageModel { public string Message { get; set; } string.Empty; public void OnGet() { Message Hello from Razor Pages!; } }2.3 与 MVC 的核心形态差异对比仓库 ui-mvc.mdMVC 需要builder.Services.AddControllersWithViews();与app.MapControllerRoute(...)通过控制器 action 处理请求而 Razor Pages没有控制器层请求直接由页面文件 PageModel 承接。这正是页面即端点与控制器即端点的本质区别。三、路由模型文件系统即 URL 结构ui-razor-pages.md 对路由模型给出最简明的三条规则默认情况下文件系统位置决定路由Pages/Index.cshtml映射到/Pages/Store/Index.cshtml映射到/Store由此衍生出的工程准则文件夹结构必须有意义因为它会成为 URL 结构。例如Pages/ ├── Index.cshtml → / ├── Store/ │ ├── Index.cshtml → /Store │ ├── Products.cshtml → /Store/Products │ └── Orders/ │ ├── Index.cshtml → /Store/Orders │ └── Detail.cshtml → /Store/Orders/Detail这条规则的直接推论规划新页面时先想清楚 URL 与导航层级再决定文件放在哪个文件夹不要用无意义的扁平目录堆页面否则 URL 结构会失去可读性需要更灵活的路由时page指令支持路由模板参数如page {id:int}但默认文件系统路由已覆盖绝大多数页面场景。四、PageModel 处理器指南OnGet / OnPost 与命名 handler4.1 处理器方法PageModel 通过约定命名的方法处理不同 HTTP 谓词OnGet→ 处理 GET 请求页面首次加载、链接跳转OnPost→ 处理 POST 请求表单提交命名 handlernamed handlers→ 同一页面处理多个语义不同的操作例如OnPostDelete、OnPostApprove在表单/链接中通过asp-page-handler或handler路由值指定4.2 表单处理绑定属性 模型验证ui-razor-pages.md 明确要求使用可绑定属性bindable properties和模型验证处理表单使用 Tag Helpers 和模型绑定而不是手工解析请求。典型表单页Pages/Products/Create.cshtml.cspublic class CreateModel : PageModel { private readonly IProductService _service; public CreateModel(IProductService service) { _service service; } [BindProperty] public ProductInput Input { get; set; } new(); public void OnGet() { // 初始化页面需要的下拉选项等 } public async TaskIActionResult OnPostAsync() { if (!ModelState.IsValid) { return Page(); // 校验失败重新渲染当前页并回显错误 } await _service.CreateAsync(Input); return RedirectToPage(./Index); // POST-Redirect-GET } }配合 Tag Helpers 的表单视图Pages/Products/Create.cshtmlpage model CreateModel form methodpost div asp-validation-summaryAll/div div label asp-forInput.Name/label input asp-forInput.Name / span asp-validation-forInput.Name/span /div button typesubmit创建/button /form要点拆解[BindProperty]让Input自动参与模型绑定无需手写Request.Form[...]asp-for、asp-validation-for、asp-validation-summary等 Tag Helpers 自动生成 name/id/校验消息规避手工拼接 HTML 的低级错误校验失败返回Page()重新渲染并展示ModelState中的错误成功操作采用POST-Redirect-GET模式RedirectToPage避免刷新重复提交——这与仓库 ui-mvc.md 对 MVC 表单提交的要求完全一致。4.3 让 PageModel 保持薄ui-razor-pages.md 给出的四条 PageModel 铁律用OnGet、OnPost与命名 handler 处理请求用可绑定属性与模型验证处理表单保持页面模型薄thin把业务逻辑移入注入的服务injected services用 Tag Helpers 与模型绑定而非手工解析请求这与仓库 program-and-pipeline.md 的架构默认一致把业务逻辑放在服务中而不是控制器、页面模型或路由 handler 中并默认使用构造函数注入constructor injection服务生命周期按 singleton无状态/共享基础设施、scoped请求级工作如DbContext、transient轻量无状态三类理性选择。4.4 页面级授权与防伪从仓库 security-and-identity.md 的边界防护原则看Razor Pages 应用应在PageModel 层施加[Authorize]可作用于页面模型类并通过RequireAuthorization()施加于端点同时cookie 交互式应用与表单提交必须启用防伪antiforgery保护——Razor Pages 的formTag Helper 会自动生成并校验防伪令牌。需要强调的是Razor Pages 的授权以页面为粒度这一特点正是下文第五节要展开的关键限制。五、关键限制与应对per-handler 授权5.1 限制本身ui-razor-pages.md 明确指出不要依赖 Razor Pages 的 per-handler 授权。当同一逻辑面上的不同 handler 需要不同授权行为时微软明确建议改用 MVC 控制器。原因在于Razor Pages 的授权粒度为页面PageModel级别[Authorize]作用于整个页面模型类而同一页面上的OnGet/OnPost/命名 handler 无法各自声明独立的授权策略。若一个页面里查看允许匿名、删除仅限管理员Razor Pages 的授权模型无法干净表达这种差异。5.2 官方建议的两种应对ui-razor-pages.md 给出两种首选应对把 handler 拆分到独立页面split the handlers into separate pages将不同授权语义的操作拆成不同页面每个页面拥有独立的[Authorize]粒度问题随即消失把该表面迁移到 MVCmove the surface to MVC当 action 级授权更契合业务时将这块逻辑面改为 MVC 控制器利用 action 级[Authorize]与授权过滤器获得精确控制。仓库 ui-mvc.md 在选择 MVC 而非 Razor Pages一节给出了同源结论当以下任一条件成立时优先 MVC——多个相关 action 共享控制器级行为handler 级授权或 action 过滤器很重要URL 与 action 设计比页面文件路由更自然5.3 其它隐含注意点不要在页面逻辑里把所有决策硬编码为角色判断仓库 security-and-identity.md 建议使用策略policies与声明claims做授权遇到上述限制时先评估拆分页面是否更简单再考虑引入 MVCSKILL.md 的默认假设也提醒尊重现有应用模型没有明确理由不要把 Razor Pages 重写为 MVC。六、组织规范文件夹、分部视图、区域与共享布局ui-razor-pages.md 最后给出四条组织层面的指导把相关页面分组到文件夹Group related pages into folders如上面第三节所示文件夹即 URL合理的分组同时优化了 URL 与代码导航对重复片段使用分部视图Use partial views for repeated fragments公共表单区块、分页控件、状态提示等抽成_partial避免复制粘贴仅在应用存在清晰有界分区时使用区域Use areas only when the application has clear bounded sections例如 Admin、BackOffice 这样的大型独立分区这与仓库 program-and-pipeline.md 中仅在应用大到足以受益于有界分区时使用 Areas的表述一致——不要为了用 Areas 而用 Areas集中维护共享布局与页面约定Keep shared layout and page conventions centralized_Layout.cshtml、_ViewImports.cshtml全局using/Tag Helper 声明、_ViewStart.cshtml集中管理保持全站视觉与结构一致。对较大项目可结合仓库 program-and-pipeline.md 的架构默认优先垂直切片/特性文件夹避免把代码堆进弱边界的巨型 Controllers/Services/Repositories 桶。七、与整体技能流程的衔接在仓库的 aspnet-core 技能工作流中Razor Pages 作为且仅作为一个主应用模型参考被加载references/ui-razor-pages.md与 Blazor、MVC、Minimal/控制器 API 并列互斥跨切面需求再按需追加 security-and-identity.md、data-state-and-services.md、testing-performance-and-operations.md 等参考。_sections.md 给出的推荐路径是新建应用走stack-selection→program-and-pipeline→ 一个主应用模型参考 →security-and-identity→testing-performance-and-operations。也就是说Razor Pages 决策通常发生在选型阶段stack-selection.md随后按 program-and-pipeline.md 的启动形态与中间件顺序组装应用。实操中可遵循的完整落地清单dotnet new webapp创建 Razor Pages 项目.NET 10 SDK 下默认模板在Program.cs中builder.Services.AddRazorPages();app.MapRazorPages();按 URL 结构规划Pages/文件夹树简单页面用page 内联 Razor复杂页面把逻辑放入配对的PageModel表单一律走[BindProperty] Tag Helpers 模型验证 POST-Redirect-GET业务逻辑下沉到注入的服务DI 合适的生命周期需要页面级安全时在 PageModel/端点上施加[Authorize]启用防伪保护遇到同一页面不同 handler 需不同授权时拆分页面或迁移到 MVC相关页面分组、重复片段抽分部视图、共享布局集中维护。结语Razor Pages 是 ASP.NET Core 中页面即端点的服务端渲染模型在表单密集的内部工具、CRUD、账号流程与后台管理场景中拥有最低的仪式成本与最清晰的表达力。它的默认文件系统路由让 URL 结构可预测PageModel 处理器让每个页面的请求逻辑集中且可测其最重要的边界在于授权粒度——当业务需要 per-handler 级授权时应果断拆分页面或切换到 MVC。结合本仓库 aspnet-core 技能提供的选型矩阵、启动流水线、安全与组织规范等配套参考你可以在具体项目中快速判断是否该用 Razor Pages并把它用对、用规范。【免费下载链接】skillsSkills Catalog for Codex项目地址: https://gitcode.com/GitHub_Trending/skills4/skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考