前言：别让“脏数据”搞垮你的系统
在上一篇中，我们实现了数据的增删改查。但现实是残酷的：前端可能会传给你一个空的标题、负数的ID，甚至是一段恶意脚本。如果我们不做防御，这些“脏数据”会像病毒一样侵入数据库。
作为一个有追求的开发者，不仅要“能写”，还要“能防”。这一篇，我们来打造系统的“安全盾牌”。
二、第一道防线：模型绑定与基础验证
ASP.NET Core 自带了基础的验证机制。当请求体（Body）中的JSON数据被反序列化为对象时，框架会自动检查数据注解。
2.1 使用 Data Annotations (数据注解)
这是最简单的方式，通过给属性加“标签”来定义规则。
修改Models/TodoItem.cs：
using 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 List<ValidationResult>(); // 执行验证 bool isValid = Validator.TryValidateObject(todo, validationContext, validationResults, true); if (!isValid) { // 如果验证失败，返回400错误和具体错误信息 return Results.BadRequest(validationResults.Select(r => r.ErrorMessage)); } // 验证通过，执行业务逻辑... return Results.Ok("数据合法"); });刚子小贴士： 这种方式虽然简单，但缺点很明显：验证规则写在了实体类里，导致类变得臃肿。而且复杂的逻辑（比如“标题不能包含敏感词”）很难用标签实现。在企业级项目中，我们更推荐下面要讲的FluentValidation。
三、进阶利器：FluentValidation
FluentValidation 是一个第三方库，它允许你用流式代码定义验证规则，将验证逻辑与实体类彻底分离。
3.1 安装与基础配置
执行命令安装包：
dotnet add package FluentValidation.AspNetCore3.2 定义验证器
创建Validators/TodoItemValidator.cs：
using FluentValidation; using MyTodoApp.Models; public class TodoItemValidator : AbstractValidator<TodoItem> { 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.AddValidatorsFromAssemblyContaining<Program>(); // 扫描当前程序集的所有验证器改造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.cs：
var app = builder.Build(); // --- 全局异常处理中间件 --- app.UseExceptionHandler(errorApp => { errorApp.Run(async context => { // 1. 获取异常详情 var exceptionHandlerFeature = context.Features.Get<IExceptionHandlerFeature>(); 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里的具体错误信息，方便调试。
