简介这份资源面向正在学习 .NET 前端开发、希望掌握 Blazor WebAssembly 身份验证流程的 C# 开发者提供了一套无需真实服务端即可跑通的登录与注册模块示例。项目以伪造后端为核心思路用模拟数据与浏览器本地存储替代真实 API涵盖组件化页面、表单验证、状态管理、路由导航、认证状态与错误提示等关键环节适合作为入门练手或课程演示的参考工程。压缩包共 61 个文件约 828KB以 16 个 cs 源文件与 15 个 razor 组件为主体辅以 json 配置、css 样式及字体图标等静态资源目录按 Models、Services、Pages、Shared、Helpers 等分层组织结构清晰便于按模块阅读。目前已有 500 人学习下载读者可从中了解 FakeBackendHandler 模拟请求、AccountService 与 LocalStorageService 协作维护会话、Alert 组件统一反馈等实现思路并借鉴其分层方式快速搭建自己的 Blazor 认证原型。1. 一个假后端把 Blazor 登录注册的坑全暴露了做 Blazor 项目最尴尬的阶段不是不会写组件而是登录注册还没接真后端前端路由、鉴权状态、表单校验全卡在半空。这个资源给了一个很实用的解法用伪造后端fake backend先把登录和注册模块跑通前端该有的交互、跳转、错误提示一个不少等真接口就位再替换数据层。它适合两类人——刚接触 Blazor 想搞懂认证流程怎么串起来的 C# 开发者以及手上有个 Demo 急着演示登录态、又不想临时搭一套用户服务的从业者。整个模块围绕 C# 和 Blazor 的组件模型展开重点不在后端多真而在前端认证链路是否完整可复现。2. 伪造后端的设计取舍为什么不是随手写个 if2.1 假后端要假到什么程度才算够用很多人一听“伪造后端”第一反应是组件里写个if (username admin)就完事。这种写法在演示时能过但只要涉及注册后立刻登录、重复用户名拦截、密码错误提示这几条路径就会立刻翻车——因为真实后端的返回结构、延迟、失败分支全被抹平了。这个资源的做法是把假后端抽成一个独立的服务类对外暴露和真 HTTP 接口同构的方法签名内部用内存集合模拟用户表。这样组件层完全不知道背后是假的将来换成HttpClient调用真接口时改动只落在服务实现里。判断假后端够不够用我一般看三条方法签名是否和未来真接口一致、返回类型是否包含成功/失败两种结果、是否模拟了最基本的异步延迟。前两条决定替换成本第三条决定你在写 loading 状态时会不会漏掉分支。这个资源在这三点上是达标的服务方法返回的是带状态的结果对象而不是裸的布尔值这一点比很多教学 Demo 讲究。2.2 服务层与组件层的边界怎么切Blazor 里最容易写乱的地方是把校验逻辑一半放组件、一半放服务。这个资源的切法是格式校验邮箱格式、密码长度、两次密码一致留在组件的EditForm和 DataAnnotations 里业务校验用户名是否已存在、密码是否匹配放服务层。这条线划清楚之后组件只负责收集输入和展示结果服务只负责判定测试和替换都简单。下面是我按这个思路整理的服务接口定义字段命名和返回结构可以直接抄// 认证服务接口组件只依赖这个抽象不关心背后是假数据还是真接口 public interface IAuthService { // 注册返回结果对象而非 bool便于携带错误信息 TaskAuthResult RegisterAsync(RegisterRequest request); // 登录成功时返回用户标识失败时返回原因 TaskAuthResult LoginAsync(LoginRequest request); } // 统一结果对象Success Message UserId 三件套够覆盖绝大多数分支 public class AuthResult { public bool Success { get; set; } public string? Message { get; set; } public string? UserId { get; set; } } public class RegisterRequest { public string UserName { get; set; } ; public string Email { get; set; } ; public string Password { get; set; } ; } public class LoginRequest { public string UserName { get; set; } ; public string Password { get; set; } ; }接口里刻意没有把密码哈希、令牌签发这些东西暴露出来因为假后端阶段这些都属于“将来再说”的部分。AuthResult用可空字符串承载错误信息组件拿到Success false时直接把Message丢给提示条即可不需要在组件里再翻译一遍错误码。UserId在登录成功后写入后续页面做“当前用户”展示时用得上。2.3 内存用户表的实现与线程安全假后端的用户表用ListUserRecord还是Dictionarystring, UserRecord差别在重复用户名的判定效率。注册时要先查重字典的键用规范化后的用户名统一转小写查重就是 O(1)。这里有个容易被忽略的点Blazor Server 模式下多个电路circuit共享同一个单例服务并发注册同一用户名时先查后插存在竞态。演示场景下概率极低但如果你的 Demo 要给多人同时点加个锁是稳妥的。// 假后端实现单例注册内存字典存用户 public class FakeAuthService : IAuthService { // 键为小写用户名值为用户记录static 保证跨组件共享 private static readonly Dictionarystring, UserRecord Users new(); private static readonly object Gate new(); public TaskAuthResult RegisterAsync(RegisterRequest request) { var key request.UserName.Trim().ToLowerInvariant(); lock (Gate) // 防并发重复注册 { if (Users.ContainsKey(key)) return Task.FromResult(new AuthResult { Success false, Message 用户名已存在 }); Users[key] new UserRecord { UserId Guid.NewGuid().ToString(N), UserName request.UserName.Trim(), Email request.Email.Trim(), // 演示用明文真项目必须换哈希 Password request.Password }; } return Task.FromResult(new AuthResult { Success true, UserId Users[key].UserId }); } public TaskAuthResult LoginAsync(LoginRequest request) { var key request.UserName.Trim().ToLowerInvariant(); lock (Gate) { if (!Users.TryGetValue(key, out var user)) return Task.FromResult(new AuthResult { Success false, Message 用户不存在 }); if (user.Password ! request.Password) return Task.FromResult(new AuthResult { Success false, Message 密码错误 }); return Task.FromResult(new AuthResult { Success true, UserId user.UserId }); } } }static字典是刻意的因为假后端服务通常注册为单例用实例字段也行但静态字段在热重载时行为更可预期。lock包住查重和插入两步避免两个请求同时通过查重。密码明文存储只在这个演示语境下成立代码注释里已经标了替换点真接后端时这一整段会被 HTTP 调用替掉所以不必在这里纠结哈希算法。3. 登录注册组件的落地步骤从表单到跳转3.1 EditForm 与 DataAnnotations 的组合用法Blazor 的表单校验靠EditForm加模型上的特性标注这套组合的好处是校验规则跟着模型走组件里不用手写一堆 if。注册模型上标[Required]、[EmailAddress]、[StringLength]EditForm的OnValidSubmit只在全部通过后触发OnInvalidSubmit用来做整体提示。这里有个细节StringLength的最小长度要设否则空密码能过[Required]之外的检查。// 注册模型校验规则集中在模型上组件不重复写 public class RegisterModel { [Required(ErrorMessage 用户名必填)] [StringLength(20, MinimumLength 3, ErrorMessage 用户名 3-20 位)] public string UserName { get; set; } ; [Required(ErrorMessage 邮箱必填)] [EmailAddress(ErrorMessage 邮箱格式不对)] public string Email { get; set; } ; [Required(ErrorMessage 密码必填)] [StringLength(64, MinimumLength 6, ErrorMessage 密码至少 6 位)] public string Password { get; set; } ; [Compare(nameof(Password), ErrorMessage 两次密码不一致)] public string ConfirmPassword { get; set; } ; }[Compare]是这套模型里最省事的一个特性两次密码一致性不用在提交时手写判断。MinimumLength一定要显式给只写[Required]的话单字符密码也能提交这是新手最常见的漏配。错误信息用中文写在特性里组件模板里用ValidationMessage直接渲染不需要额外维护一份提示文案。3.2 提交处理与导航跳转的时序OnValidSubmit里做三件事置 loading、调服务、按结果决定跳转或提示。顺序不能乱尤其是导航要在状态更新之后。Blazor 的NavigationManager.NavigateTo是同步调用但导航是异步生效的如果先导航再写登录态目标页可能读到空状态。正确顺序是先写状态、再导航。// 登录组件片段提交处理与跳转时序 private bool loading; private string? error; private async Task HandleLogin() { loading true; error null; var result await AuthService.LoginAsync(new LoginRequest { UserName model.UserName, Password model.Password }); loading false; if (!result.Success) { error result.Message; // 失败只更新提示不跳转 return; } // 先落登录态再导航避免目标页读到空值 await AuthState.MarkUserAuthenticated(result.UserId!); NavigationManager.NavigateTo(/dashboard); }loading标志要包住整个异步调用按钮的disabled绑到它上面防止用户连点造成重复提交。error在每次提交前清空否则上一次的错误会残留。MarkUserAuthenticated是我习惯的命名内部把用户标识写进一个作用域服务或受保护存储具体存哪取决于你用 Server 还是 WebAssembly但“先写后跳”这个顺序是通用的。3.3 登录态在组件间的传递方式登录成功后其他页面要知道“当前是谁”。Blazor 里常见三种做法级联值CascadingValue、作用域服务、受保护浏览器存储。演示项目用作用域服务最直接注册为 Scoped登录时写入、页面注入读取。WebAssembly 模式下刷新会丢需要配合localStorageServer 模式下 Scoped 生命周期跟电路走刷新同样会重置。这个资源作为演示用服务内存态即可但要知道它的边界在哪。// 登录态服务Scoped 注册页面注入读取 public class AuthState { public string? UserId { get; private set; } public bool IsAuthenticated !string.IsNullOrEmpty(UserId); public Task MarkUserAuthenticated(string userId) { UserId userId; return Task.CompletedTask; } public void Logout() UserId null; }IsAuthenticated做成计算属性而不是独立字段避免两处状态不同步。MarkUserAuthenticated返回Task是为了将来换成写localStorage时签名不用改现在直接返回完成态。Logout只清内存如果接了持久化要在这里一并清存储这个替换点值得在代码里留注释。4. 避坑与排查假后端阶段最容易翻车的几处4.1 刷新页面登录态丢失被误判成“认证没生效”现象是登录后跳转正常一按 F5 就回到未登录路由守卫把人踢回登录页。原因在于登录态只存在 Scoped 服务的内存里页面刷新会重建电路或重载程序集内存态自然清空。解决方式分两种演示阶段可以接受就在路由守卫里对未认证访问做友好跳转而不是白屏要真持久化就在MarkUserAuthenticated里写localStorage或受保护存储并在应用启动时读回。别在组件OnInitialized里各写各的读取逻辑统一放服务里。4.2 重复注册没拦住问题出在大小写现象是注册Alice成功后再注册alice也成功登录时却只有一个能进。原因是查重用了原始字符串做键大小写被当成不同用户。解决是在写入和查询前统一ToLowerInvariant()并且Trim()掉首尾空格。这个坑在演示时不容易发现因为测试的人往往只用一个大小写形式等演示现场有人换个大小写就露馅。4.3 表单提交后错误提示不消失现象是第一次密码错误提示“密码错误”改成正确密码再提交提示还在。原因是error字段只在失败分支赋值成功分支没清。解决是在每次提交开始时把error置空或者成功分支显式清空。这类状态残留是 Blazor 表单里最高频的低级错误凡是“上次的结果影响这次展示”的字段都要在提交入口统一重置。4.4 导航后目标页读不到用户时序反了现象是登录成功跳转后目标页的OnInitialized里IsAuthenticated还是 false。原因是先调了NavigateTo再写状态或者状态写入是异步的但没await。解决是严格按“await 写状态 → 再导航”的顺序并且确认写状态的方法真的被await了。如果状态写入涉及存储 IO漏await几乎必现这个 bug。4.5 假后端服务注册成 Transient数据每次都是新的现象是注册成功登录却提示用户不存在。原因是服务注册成了Transient每次注入都是新实例内存字典跟着重建。解决是把假后端注册为Singleton或至少Scoped保证同一生命周期内用户表是同一份。这个坑的迷惑性在于代码逻辑完全正确错在Program.cs里一行注册。提示假后端阶段的所有“数据丢失”类问题先查服务生命周期再查持久化最后才怀疑业务逻辑顺序反了会浪费大量时间。5. 从假到真的替换路径与验证清单把假后端换成真接口改动面比想象中小前提是前面几章的边界切对了。替换动作集中在三处IAuthService的实现类换成基于HttpClient的版本、AuthResult的字段映射到真接口的响应结构、登录态的持久化从内存换成存储。组件层理论上零改动如果发现要改组件说明当初把业务判定漏在了组件里。下面是我替换时会走的一张对照表用来确认没有遗漏检查项假后端阶段替换为真接口后服务注册Singleton 内存实现Scoped HttpClient返回结构AuthResult 三字段映射真响应的 code/message/data密码处理明文比对只传原文哈希在服务端登录态内存 Scoped存储 启动时读回错误提示服务返回中文按错误码映射文案替换后第一件事不是点页面而是先验证失败分支错误密码、不存在用户、重复注册、空字段提交四条路径逐条走一遍。真接口最容易和假后端不一致的地方就是失败时的返回结构假后端里Message一定有值真接口可能返回空 message 只给错误码组件拿到空字符串就会显示空白提示。我一般会在映射层给Message兜一个默认文案避免这种“成功路径都对、失败路径白屏”的尴尬。还有一个验证习惯值得养成替换完成后把IAuthService临时换回假实现跑一遍同样的四条路径如果两边行为一致说明抽象层是干净的如果换回假实现后组件报错说明组件偷偷依赖了真实现的某个细节这个依赖迟早会在下次接口调整时咬你一口。从那以后我每次做这种“假替真”的迁移都强制走一遍双向切换验证宁可多花十分钟也不想在演示前夜对着一个空提示框排查到凌晨。希望帮到你。本文还有配套的精品资源点击获取