Blazor脚手架生成的注册页为何是.cshtml格式而非.razor组件？

脚手架默认输出.cshtml而非Razor组件的核心原因 #

• 历史兼容性是首要因素：ASP.NET Core Identity体系的诞生远早于Blazor，整套内置UI、业务逻辑都是基于Razor Pages/MVC架构实现的，脚手架工具只是将这套经过长时间验证的成熟实现直接导出供开发者自定义，官方至今没有投入资源做全量的Blazor组件化迁移，自然不会默认生成.razor文件。
• 流程适配性需求：身份相关的很多场景（比如第三方OAuth回调、邮箱验证链接跳转、密码重置令牌校验）需要在请求到达的第一时间完成处理，.cshtml走传统HTTP请求响应流程，不需要等待Blazor的SignalR长连接初始化，响应速度更快，也不会出现长连接初始化失败导致的身份操作失效问题。
• 安全性确实是核心考量之一：默认生成的.cshtml身份页面已经过微软多年的安全审计，所有敏感操作都是无状态的单次请求校验，不需要维持长连接，规避了Blazor长连接会话劫持、状态意外泄露的潜在风险；官方没有默认提供Blazor版本的另一个原因，就是避免没有安全开发经验的开发者自行修改核心逻辑引入漏洞。

重写为Blazor组件是否是合理方案 #

完全合理，目前已经有大量生产环境项目这么做，但需要严格遵守几个安全规则：

• 核心逻辑完全复用官方实现：所有身份操作直接调用UserManager、SignInManager的原生公开接口，不要自行实现密码哈希、令牌校验、Cookie颁发这类底层逻辑。
• 敏感数据不要存入Blazor状态：密码、重置令牌、二次校验码这类敏感信息不要存在Blazor组件的参数、级联参数或者任何状态管理容器中，提交后直接传递给官方接口即可，不要做额外的缓存、传递。
• 特殊场景保留.cshtml实现：涉及外部回调、令牌校验的页面（比如邮箱确认、第三方登录回调）建议还是保留.cshtml实现，避免令牌被传递到Blazor的客户端上下文造成泄露。

只要严格遵循上面的要求，重写后的Blazor身份页面的安全性是完全有保障的，也能实现全站UI风格统一的优化目标。

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