构建盾牌——数据验证与全局异常处理

前言别让“脏数据”搞垮你的系统在上一篇中我们实现了数据的增删改查。但现实是残酷的前端可能会传给你一个空的标题、负数的ID甚至是一段恶意脚本。如果我们不做防御这些“脏数据”会像病毒一样侵入数据库。作为一个有追求的开发者不仅要“能写”还要“能防”。这一篇我们来打造系统的“安全盾牌”。二、第一道防线模型绑定与基础验证ASP.NET Core 自带了基础的验证机制。当请求体Body中的JSON数据被反序列化为对象时框架会自动检查数据注解。2.1 使用 Data Annotations (数据注解)这是最简单的方式通过给属性加“标签”来定义规则。修改Models/TodoItem.csusing System.ComponentModel.DataAnnotations; public class TodoItem { public int Id { get; set; } [Required(ErrorMessage 标题不能为空)] // 必填 [StringLength(100, ErrorMessage 标题长度不能超过100)] // 最大长度 public string? Title { get; set; } public bool IsDone { get; set; } public DateTime CreatedAt { get; set; } DateTime.Now; }2.2 在API中检查验证状态在Minimal API中我们需要手动检查ValidationContext这比传统Controller稍微麻烦一点但更灵活。using System.ComponentModel.DataAnnotations; app.MapPost(/todos/basic-validate, (TodoItem todo) { // 手动创建验证上下文 var validationContext new ValidationContext(todo); var validationResults new ListValidationResult(); // 执行验证 bool isValid Validator.TryValidateObject(todo, validationContext, validationResults, true); if (!isValid) { // 如果验证失败返回400错误和具体错误信息 return Results.BadRequest(validationResults.Select(r r.ErrorMessage)); } // 验证通过执行业务逻辑... return Results.Ok(数据合法); });刚子小贴士 这种方式虽然简单但缺点很明显验证规则写在了实体类里导致类变得臃肿。而且复杂的逻辑比如“标题不能包含敏感词”很难用标签实现。在企业级项目中我们更推荐下面要讲的FluentValidation。三、进阶利器FluentValidationFluentValidation 是一个第三方库它允许你用流式代码定义验证规则将验证逻辑与实体类彻底分离。3.1 安装与基础配置执行命令安装包dotnet add package FluentValidation.AspNetCore3.2 定义验证器创建Validators/TodoItemValidator.csusing FluentValidation; using MyTodoApp.Models; public class TodoItemValidator : AbstractValidatorTodoItem { public TodoItemValidator() { // 规则1标题不为空 RuleFor(x x.Title) .NotEmpty().WithMessage(任务标题必须填写) .MaximumLength(50).WithMessage(标题太长了别超过50个字); // 规则2自定义逻辑验证 RuleFor(x x.Title) .Must(title !title.Contains(傻子)).WithMessage(标题包含敏感词请文明用语); } }3.3 注册与自动验证在Program.cs中注册服务builder.Services.AddFluentValidationAutoValidation(); // 开启自动验证 builder.Services.AddValidatorsFromAssemblyContainingProgram(); // 扫描当前程序集的所有验证器改造API接口 现在当请求进入时框架会自动验证。如果失败直接返回400。我们可以这样写app.MapPost(/todos, (TodoItem todo, AppDbContext db) { // 如果走到这里说明验证已经通过了 db.Todos.Add(todo); db.SaveChanges(); return Results.Created($/todos/{todo.Id}, todo); });刚子敲黑板 FluentValidation 最强大的地方在于它的可复用性和可测试性。你可以单独对这个 Validator 类写单元测试确保验证逻辑的正确性而不用担心业务逻辑的干扰。四、第二道防线全局异常处理只有验证是不够的。代码运行时总会遇到意想不到的错误数据库连接断了、文件找不到了、甚至是你写了int.Parse(abc)。如果不管这些异常用户会看到浏览器返回一个黄色的错误页面开发环境或者裸露的堆栈信息生产环境这非常不专业甚至可能泄露敏感代码路径。4.1 构建统一响应格式我们需要定义一个标准的错误返回格式无论哪里出错前端收到的结构都是一样的。// 定义错误响应模型 public class ErrorResponse { public int StatusCode { get; set; } public string Message { get; set; } public string? Detail { get; set; } // 仅开发环境显示 }4.2 编写异常处理中间件我们在管道的最前端放置一个“捕鱼网”捕获所有后续抛出的异常。修改Program.csvar app builder.Build(); // --- 全局异常处理中间件 --- app.UseExceptionHandler(errorApp { errorApp.Run(async context { // 1. 获取异常详情 var exceptionHandlerFeature context.Features.GetIExceptionHandlerFeature(); var exception exceptionHandlerFeature?.Error; // 2. 设置响应状态码和内容类型 context.Response.StatusCode 500; context.Response.ContentType application/json; // 3. 构造返回对象 var response new ErrorResponse { StatusCode 500, Message 服务器内部错误请稍后重试, // 给用户看的友好信息 Detail app.Environment.IsDevelopment() ? exception?.Message : null // 开发环境下显示具体错误 }; // 4. 序列化并返回 await context.Response.WriteAsJsonAsync(response); }); }); // ... 其他中间件 ...4.3 实战模拟异常我们故意写一个会报错的接口app.MapGet(/error-test, () { throw new Exception(哎呀这里发生了一个模拟的严重错误); return 这里永远走不到; });访问这个接口在生产环境下用户会看到{ statusCode: 500, message: 服务器内部错误请稍后重试, detail: null }而在开发环境下你作为开发者可以看到detail里的具体错误信息方便调试。