在实际企业级 Web 开发中选择一个稳定、高效且生态丰富的后端框架是项目成功的基础。.NET 平台下的 ASP.NET Core 框架凭借其跨平台、高性能和模块化设计已成为构建现代 Web API、微服务及实时应用的主流选择之一。对于从 .NET Framework 迁移而来的开发者或希望利用 C# 强类型语言优势构建 Web 服务的团队深入掌握 ASP.NET Core 的核心机制与工程实践至关重要。本文将以一个可运行的 Web API 项目为主线带你从零开始理解 ASP.NET Core 的启动流程、中间件管道、依赖注入容器以及配置系统并详细拆解开发、调试到部署的完整链路同时提供生产环境中常见的配置、排错与性能优化建议。1. 理解 ASP.NET Core 的核心架构与启动流程在编写第一行代码之前需要先理解 ASP.NET Core 是如何工作的。它不是一个黑盒其设计遵循了明确的约定和管道模型。1.1 应用程序启动Program.cs 与 Startup 模式ASP.NET Core 应用的入口是Program.cs文件。在 .NET 6 及更高版本中微软引入了“最小托管模型”将Program.cs和Startup.cs的功能合并使代码更加简洁。但理解传统的Startup模式有助于理解各个组件的职责。传统的Startup类包含两个主要方法ConfigureServices用于向依赖注入容器注册服务。Configure用于配置应用程序的请求处理管道。在新的最小托管模型中这些操作直接在Program.cs中完成。以下是一个最小托管模型的示例// Program.cs var builder WebApplication.CreateBuilder(args); // 1. 配置服务 (对应传统的 ConfigureServices) builder.Services.AddControllers(); // 添加控制器支持 builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); // 添加 Swagger/OpenAPI 支持 var app builder.Build(); // 2. 配置 HTTP 请求管道 (对应传统的 Configure) if (app.Environment.IsDevelopment()) { app.UseSwagger(); app.UseSwaggerUI(); } app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers(); // 映射控制器路由 app.Run();这段代码清晰地展示了 ASP.NET Core 应用的两个核心阶段服务配置和应用构建/管道配置。WebApplication对象是托管和运行 Web 应用的核心。1.2 中间件管道HTTP 请求的生命周期ASP.NET Core 处理 HTTP 请求的过程是一个中间件管道。每个中间件组件都可以选择是否将请求传递给管道中的下一个组件。在请求之前和之后执行工作。管道配置的顺序至关重要它决定了请求处理的逻辑流。常见的中间件及其顺序如下// 正确的中间件顺序示例 app.UseExceptionHandler(/error); // 1. 全局异常处理开发环境可能用 UseDeveloperExceptionPage app.UseHttpsRedirection(); // 2. HTTPS 重定向 app.UseStaticFiles(); // 3. 静态文件服务 app.UseRouting(); // 4. 路由匹配 app.UseAuthentication(); // 5. 身份认证 app.UseAuthorization(); // 6. 授权 app.MapControllers(); // 7. 终结点路由如 MVC/Web API // app.MapRazorPages(); // 或者 Razor Pages如果顺序错误例如将UseAuthentication放在UseRouting之前路由信息可能无法用于授权策略导致功能异常。1.3 依赖注入内置的 IoC 容器依赖注入是 ASP.NET Core 的基石。框架内置了一个轻量级的 IoC 容器用于管理服务的生命周期。理解三种主要的生命周期至关重要生命周期注册方法描述典型使用场景瞬时AddTransientT每次请求时创建新实例。无状态服务如工具类、计算器。作用域AddScopedT在同一 Web 请求范围内是同一个实例。数据库上下文 (DbContext)、仓储、有状态的服务。单例AddSingletonT在整个应用生命周期内只有一个实例。配置对象、缓存服务、日志器。错误地选择生命周期会导致严重问题例如将DbContext注册为单例会引起数据并发访问错误和内存泄漏。2. 环境准备与项目初始化在开始编码前需要确保本地开发环境配置正确。2.1 安装 .NET SDK首先需要安装 .NET SDK。访问 .NET 官方网站 下载并安装与你的操作系统对应的最新长期支持版本。安装后在终端中运行以下命令验证dotnet --version此命令应输出已安装的 SDK 版本号例如8.0.201。2.2 创建新的 Web API 项目使用 .NET CLI 可以快速创建项目骨架。打开终端导航到你的工作目录执行dotnet new webapi -n MyAspNetCoreApi cd MyAspNetCoreApi此命令会创建一个名为MyAspNetCoreApi的新目录其中包含一个基础的 Web API 项目模板。关键文件和目录包括Program.cs应用入口和配置。appsettings.json应用配置文件。Controllers/存放 Web API 控制器。Properties/launchSettings.json调试启动配置文件。2.3 项目结构解析与关键配置查看生成的appsettings.json这是默认的配置文件支持 JSON 格式。{ Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } }, AllowedHosts: * }Logging配置日志级别生产环境通常将Microsoft.AspNetCore设为Warning以减少噪音。AllowedHosts安全配置限制可访问应用的主机头。*表示允许所有生产环境应设置为具体的域名。launchSettings.json文件定义了不同的启动配置文件Profile例如用于 IIS Express 和 KestrelASP.NET Core 内置的跨平台 Web 服务器。{ profiles: { http: { commandName: Project, dotnetRunMessages: true, launchBrowser: true, launchUrl: swagger, applicationUrl: http://localhost:5193, environmentVariables: { ASPNETCORE_ENVIRONMENT: Development } } } }注意ASPNETCORE_ENVIRONMENT环境变量被设置为Development。这个变量决定了应用运行的环境会影响配置加载、异常页面显示等行为。3. 构建一个完整的待办事项 API我们将构建一个简单的待办事项管理 API涵盖控制器、模型、服务层和内存数据存储以此演示 ASP.NET Core 的核心开发模式。3.1 定义数据模型与仓储接口首先在项目根目录创建Models文件夹并添加TodoItem.cs// Models/TodoItem.cs namespace MyAspNetCoreApi.Models; public class TodoItem { public int Id { get; set; } public string? Title { get; set; } public bool IsCompleted { get; set; } public DateTime CreatedAt { get; set; } DateTime.UtcNow; }接着创建Services文件夹并定义仓储层的抽象接口ITodoRepository.cs// Services/ITodoRepository.cs using MyAspNetCoreApi.Models; namespace MyAspNetCoreApi.Services; public interface ITodoRepository { IEnumerableTodoItem GetAll(); TodoItem? GetById(int id); TodoItem Add(TodoItem item); bool Update(TodoItem item); bool Delete(int id); }3.2 实现内存仓储与服务注册实现一个基于内存列表的仓储。在Services文件夹下创建InMemoryTodoRepository.cs// Services/InMemoryTodoRepository.cs using MyAspNetCoreApi.Models; namespace MyAspNetCoreApi.Services; public class InMemoryTodoRepository : ITodoRepository { private readonly ListTodoItem _items new(); private int _nextId 1; public IEnumerableTodoItem GetAll() _items; public TodoItem? GetById(int id) _items.FirstOrDefault(i i.Id id); public TodoItem Add(TodoItem item) { item.Id _nextId; _items.Add(item); return item; } public bool Update(TodoItem updatedItem) { var index _items.FindIndex(i i.Id updatedItem.Id); if (index 0) return false; _items[index] updatedItem; return true; } public bool Delete(int id) { var item GetById(id); if (item null) return false; return _items.Remove(item); } }现在需要在Program.cs中将此服务注册到依赖注入容器。由于仓储通常与 HTTP 请求关联每个请求一个独立的仓储实例是安全的我们使用作用域生命周期。在Program.cs的builder.Services配置部分添加builder.Services.AddScopedITodoRepository, InMemoryTodoRepository();3.3 创建 API 控制器在Controllers文件夹下创建TodoController.cs。ASP.NET Core 通过特性路由和模型绑定简化了 Web API 的创建。// Controllers/TodoController.cs using Microsoft.AspNetCore.Mvc; using MyAspNetCoreApi.Models; using MyAspNetCoreApi.Services; namespace MyAspNetCoreApi.Controllers; [ApiController] [Route(api/[controller])] // 路由模板访问路径为 /api/todo public class TodoController : ControllerBase { private readonly ITodoRepository _repository; // 依赖注入构造函数注入 ITodoRepository public TodoController(ITodoRepository repository) { _repository repository; } // GET: api/todo [HttpGet] public ActionResultIEnumerableTodoItem GetAll() { return Ok(_repository.GetAll()); } // GET: api/todo/5 [HttpGet({id})] public ActionResultTodoItem GetById(int id) { var item _repository.GetById(id); if (item null) { return NotFound(); // 返回 404 状态码 } return Ok(item); } // POST: api/todo [HttpPost] public ActionResultTodoItem Create(TodoItem item) { // 模型验证自动进行如果 item 无效会返回 400 Bad Request var createdItem _repository.Add(item); // 返回 201 Created 状态码并在 Location 头中提供新资源的 URI return CreatedAtAction(nameof(GetById), new { id createdItem.Id }, createdItem); } // PUT: api/todo/5 [HttpPut({id})] public IActionResult Update(int id, TodoItem item) { if (id ! item.Id) { return BadRequest(); // 返回 400 状态码 } if (!_repository.Update(item)) { return NotFound(); } return NoContent(); // 返回 204 No Content 状态码 } // DELETE: api/todo/5 [HttpDelete({id})] public IActionResult Delete(int id) { if (!_repository.Delete(id)) { return NotFound(); } return NoContent(); } }3.4 运行与验证 API在项目根目录运行以下命令启动应用dotnet run应用启动后默认会监听http://localhost:5193和https://localhost:7193端口可能不同。打开浏览器或使用工具访问Swagger UI访问https://localhost:7193/swagger这是一个交互式的 API 文档界面可以直接测试所有端点。直接调用 API使用 curl 或 Postman。获取所有待办事项GET https://localhost:7193/api/todo创建新待办事项POST https://localhost:7193/api/todoBody 为 JSON{title: 学习 ASP.NET Core, isCompleted: false}观察控制台输出可以看到 Kestrel 服务器的启动日志和请求处理日志。4. 配置、日志与异常处理进阶一个健壮的应用离不开完善的配置、日志和异常处理机制。4.1 多环境配置管理ASP.NET Core 支持基于环境的配置。配置文件按以下顺序加载后面的覆盖前面的appsettings.jsonappsettings.{Environment}.json(例如appsettings.Development.json)环境变量命令行参数创建appsettings.Production.json文件覆盖生产环境的日志级别并添加数据库连接字符串{ Logging: { LogLevel: { Default: Warning, Microsoft.AspNetCore: Warning } }, ConnectionStrings: { DefaultConnection: Serverprod-db-server;DatabaseMyAppDb;Trusted_Connectionfalse;User Idsa;Passwordyour_strong_password; } }在代码中可以通过IConfiguration接口读取配置。例如在Program.cs中读取连接字符串var connectionString builder.Configuration.GetConnectionString(DefaultConnection);4.2 结构化日志与 Serilog 集成虽然内置日志提供程序功能齐全但生产环境更推荐使用结构化日志系统如Serilog。它可以将日志输出为 JSON 格式便于被 ELK、Seq 等日志系统收集和分析。首先安装 NuGet 包dotnet add package Serilog.AspNetCore dotnet add package Serilog.Sinks.Console dotnet add package Serilog.Sinks.File在Program.cs的最开始配置 Serilogusing Serilog; Log.Logger new LoggerConfiguration() .MinimumLevel.Information() .WriteTo.Console(outputTemplate: [{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}) .WriteTo.File(logs/myapp-.txt, rollingInterval: RollingInterval.Day) .CreateLogger(); try { var builder WebApplication.CreateBuilder(args); // 使用 Serilog 替换默认日志提供程序 builder.Host.UseSerilog(); // ... 其余服务配置 } catch (Exception ex) { Log.Fatal(ex, Application startup failed); } finally { Log.CloseAndFlush(); }在控制器或服务中通过依赖注入ILoggerT来记录日志public class TodoController : ControllerBase { private readonly ITodoRepository _repository; private readonly ILoggerTodoController _logger; public TodoController(ITodoRepository repository, ILoggerTodoController logger) { _repository repository; _logger logger; } [HttpGet({id})] public ActionResultTodoItem GetById(int id) { _logger.LogInformation(Getting todo item with ID {TodoId}, id); // 结构化日志 var item _repository.GetById(id); if (item null) { _logger.LogWarning(Todo item with ID {TodoId} not found, id); return NotFound(); } return Ok(item); } }4.3 全局异常处理与问题详情在开发环境UseDeveloperExceptionPage中间件可以提供详细的异常信息。但在生产环境我们需要一个更友好、更安全的全局异常处理机制。ASP.NET Core 提供了UseExceptionHandler中间件。我们可以创建一个专用的错误处理控制器// Controllers/ErrorController.cs using Microsoft.AspNetCore.Diagnostics; using Microsoft.AspNetCore.Mvc; namespace MyAspNetCoreApi.Controllers; [ApiController] [Route(/error)] [ApiExplorerSettings(IgnoreApi true)] // 从 Swagger 文档中隐藏 public class ErrorController : ControllerBase { [HttpGet] [HttpPost] [HttpPut] [HttpDelete] public IActionResult HandleError() { var exceptionHandlerFeature HttpContext.Features.GetIExceptionHandlerFeature(); var exception exceptionHandlerFeature?.Error; // 生产环境记录异常返回通用错误信息 // 开发环境可以返回更多细节需谨慎 var problemDetails new ProblemDetails { Status StatusCodes.Status500InternalServerError, Title An error occurred while processing your request., Detail exception?.Message // 生产环境通常不返回此信息 }; return StatusCode(StatusCodes.Status500InternalServerError, problemDetails); } }在Program.cs的管道配置中在管道顶部添加异常处理if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler(/error); // 生产环境也建议启用严格的 HTTP 安全头 app.UseHsts(); } else { app.UseDeveloperExceptionPage(); }5. 生产环境部署与性能考量将应用部署到生产环境时需要考虑性能、安全性和可维护性。5.1 发布应用使用 .NET CLI 发布应用为自包含或框架依赖的部署。# 发布为框架依赖目标机器需安装对应运行时 dotnet publish -c Release -o ./publish # 发布为自包含将运行时打包进去体积更大 dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish-linux-c Release指定使用发布配置这会启用代码优化。5.2 使用反向代理在生产环境中通常不直接对外暴露 Kestrel。而是使用反向代理服务器如 Nginx, Apache, IIS来处理静态文件、SSL 终止、负载均衡等再将请求转发给 Kestrel。一个简单的 Nginx 配置示例 (/etc/nginx/sites-available/myapp)server { listen 80; server_name yourdomain.com; location / { proxy_pass http://localhost:5000; # Kestrel 监听地址 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }注意确保 Kestrel 配置appsettings.json或Program.cs中的applicationUrl与反向代理的转发地址一致并正确配置ForwardedHeaders中间件以使应用能识别原始请求信息。5.3 性能优化建议异步编程尽可能使用async/await处理 I/O 密集型操作如数据库查询、HTTP 调用避免阻塞线程池线程。public async TaskActionResultIEnumerableTodoItem GetAllAsync() { var items await _repository.GetAllAsync(); // 假设仓储有异步方法 return Ok(items); }响应缓存对于不常变化的数据使用[ResponseCache]特性或内存缓存来减少计算和数据库压力。数据库连接池使用DbContext时EF Core 默认管理连接池。确保在appsettings.json中正确配置连接字符串。健康检查添加健康检查端点便于容器编排平台监控应用状态。dotnet add package Microsoft.AspNetCore.Diagnostics.HealthChecksbuilder.Services.AddHealthChecks(); app.MapHealthChecks(/health);6. 常见问题排查清单在开发部署过程中你可能会遇到以下问题。这里提供一份排查清单。问题现象可能原因检查步骤与解决方案dotnet run失败提示 SDK 未找到.NET SDK 未安装或未添加到 PATH 环境变量。1. 运行dotnet --version确认安装。2. 检查系统环境变量 PATH 是否包含 SDK 路径。应用启动后立即退出端口被占用或Program.cs中的app.Run()之前提前返回。1. 检查控制台错误信息。2. 使用netstat -ano查看端口占用。3. 确保app.Run()是Program.cs的最后一行。API 返回 404路由不匹配或控制器未正确注册。1. 检查控制器[Route]特性和 HTTP 方法特性。2. 确认Program.cs中调用了app.MapControllers()。3. 检查请求的 URL 和 HTTP 方法是否正确。依赖注入服务解析失败服务未注册或生命周期不匹配。1. 检查Program.cs中是否注册了该服务。2. 确认注册的生命周期Scoped/Transient/Singleton与使用场景匹配。3. 尝试在构造函数中注入而不是在方法内手动从容器解析。配置值读取为null配置键名错误或配置文件未加载。1. 使用builder.Configuration.AsEnumerable()输出所有配置项检查。2. 确认appsettings.{Environment}.json文件名和环境变量ASPNETCORE_ENVIRONMENT设置正确。3. 检查 JSON 文件格式是否正确。数据库连接失败连接字符串错误、数据库服务未启动或网络不通。1. 在Program.cs启动时打印连接字符串仅限开发环境进行核对。2. 使用数据库客户端工具测试连接。3. 检查数据库防火墙规则。静态文件无法访问未启用静态文件中间件或文件路径不正确。1. 确认Program.cs中调用了app.UseStaticFiles()。2. 静态文件应放在wwwroot目录下或使用UseStaticFiles重载指定自定义目录。Swagger 页面无法打开未注册 Swagger 服务或未启用中间件。1. 检查builder.Services.AddSwaggerGen()和app.UseSwagger()、app.UseSwaggerUI()是否已添加。2. 确认仅在开发环境启用或生产环境有相应安全措施。掌握 ASP.NET Core 不仅在于能运行一个示例项目更在于理解其管道模型、依赖注入哲学以及如何根据环境配置应用。从简单的内存存储切换到真正的数据库从开发环境切换到生产部署每一步都需要仔细考虑配置、日志和异常处理。建议在掌握本文内容后进一步探索真实数据库集成、身份认证与授权、单元测试与集成测试以及利用 Docker 容器化部署从而构建出更健壮、可维护的企业级应用。 ASP.NET Core Web API 开发实战：从核心架构到生产部署
在实际企业级 Web 开发中选择一个稳定、高效且生态丰富的后端框架是项目成功的基础。.NET 平台下的 ASP.NET Core 框架凭借其跨平台、高性能和模块化设计已成为构建现代 Web API、微服务及实时应用的主流选择之一。对于从 .NET Framework 迁移而来的开发者或希望利用 C# 强类型语言优势构建 Web 服务的团队深入掌握 ASP.NET Core 的核心机制与工程实践至关重要。本文将以一个可运行的 Web API 项目为主线带你从零开始理解 ASP.NET Core 的启动流程、中间件管道、依赖注入容器以及配置系统并详细拆解开发、调试到部署的完整链路同时提供生产环境中常见的配置、排错与性能优化建议。1. 理解 ASP.NET Core 的核心架构与启动流程在编写第一行代码之前需要先理解 ASP.NET Core 是如何工作的。它不是一个黑盒其设计遵循了明确的约定和管道模型。1.1 应用程序启动Program.cs 与 Startup 模式ASP.NET Core 应用的入口是Program.cs文件。在 .NET 6 及更高版本中微软引入了“最小托管模型”将Program.cs和Startup.cs的功能合并使代码更加简洁。但理解传统的Startup模式有助于理解各个组件的职责。传统的Startup类包含两个主要方法ConfigureServices用于向依赖注入容器注册服务。Configure用于配置应用程序的请求处理管道。在新的最小托管模型中这些操作直接在Program.cs中完成。以下是一个最小托管模型的示例// Program.cs var builder WebApplication.CreateBuilder(args); // 1. 配置服务 (对应传统的 ConfigureServices) builder.Services.AddControllers(); // 添加控制器支持 builder.Services.AddEndpointsApiExplorer(); builder.Services.AddSwaggerGen(); // 添加 Swagger/OpenAPI 支持 var app builder.Build(); // 2. 配置 HTTP 请求管道 (对应传统的 Configure) if (app.Environment.IsDevelopment()) { app.UseSwagger(); app.UseSwaggerUI(); } app.UseHttpsRedirection(); app.UseAuthorization(); app.MapControllers(); // 映射控制器路由 app.Run();这段代码清晰地展示了 ASP.NET Core 应用的两个核心阶段服务配置和应用构建/管道配置。WebApplication对象是托管和运行 Web 应用的核心。1.2 中间件管道HTTP 请求的生命周期ASP.NET Core 处理 HTTP 请求的过程是一个中间件管道。每个中间件组件都可以选择是否将请求传递给管道中的下一个组件。在请求之前和之后执行工作。管道配置的顺序至关重要它决定了请求处理的逻辑流。常见的中间件及其顺序如下// 正确的中间件顺序示例 app.UseExceptionHandler(/error); // 1. 全局异常处理开发环境可能用 UseDeveloperExceptionPage app.UseHttpsRedirection(); // 2. HTTPS 重定向 app.UseStaticFiles(); // 3. 静态文件服务 app.UseRouting(); // 4. 路由匹配 app.UseAuthentication(); // 5. 身份认证 app.UseAuthorization(); // 6. 授权 app.MapControllers(); // 7. 终结点路由如 MVC/Web API // app.MapRazorPages(); // 或者 Razor Pages如果顺序错误例如将UseAuthentication放在UseRouting之前路由信息可能无法用于授权策略导致功能异常。1.3 依赖注入内置的 IoC 容器依赖注入是 ASP.NET Core 的基石。框架内置了一个轻量级的 IoC 容器用于管理服务的生命周期。理解三种主要的生命周期至关重要生命周期注册方法描述典型使用场景瞬时AddTransientT每次请求时创建新实例。无状态服务如工具类、计算器。作用域AddScopedT在同一 Web 请求范围内是同一个实例。数据库上下文 (DbContext)、仓储、有状态的服务。单例AddSingletonT在整个应用生命周期内只有一个实例。配置对象、缓存服务、日志器。错误地选择生命周期会导致严重问题例如将DbContext注册为单例会引起数据并发访问错误和内存泄漏。2. 环境准备与项目初始化在开始编码前需要确保本地开发环境配置正确。2.1 安装 .NET SDK首先需要安装 .NET SDK。访问 .NET 官方网站 下载并安装与你的操作系统对应的最新长期支持版本。安装后在终端中运行以下命令验证dotnet --version此命令应输出已安装的 SDK 版本号例如8.0.201。2.2 创建新的 Web API 项目使用 .NET CLI 可以快速创建项目骨架。打开终端导航到你的工作目录执行dotnet new webapi -n MyAspNetCoreApi cd MyAspNetCoreApi此命令会创建一个名为MyAspNetCoreApi的新目录其中包含一个基础的 Web API 项目模板。关键文件和目录包括Program.cs应用入口和配置。appsettings.json应用配置文件。Controllers/存放 Web API 控制器。Properties/launchSettings.json调试启动配置文件。2.3 项目结构解析与关键配置查看生成的appsettings.json这是默认的配置文件支持 JSON 格式。{ Logging: { LogLevel: { Default: Information, Microsoft.AspNetCore: Warning } }, AllowedHosts: * }Logging配置日志级别生产环境通常将Microsoft.AspNetCore设为Warning以减少噪音。AllowedHosts安全配置限制可访问应用的主机头。*表示允许所有生产环境应设置为具体的域名。launchSettings.json文件定义了不同的启动配置文件Profile例如用于 IIS Express 和 KestrelASP.NET Core 内置的跨平台 Web 服务器。{ profiles: { http: { commandName: Project, dotnetRunMessages: true, launchBrowser: true, launchUrl: swagger, applicationUrl: http://localhost:5193, environmentVariables: { ASPNETCORE_ENVIRONMENT: Development } } } }注意ASPNETCORE_ENVIRONMENT环境变量被设置为Development。这个变量决定了应用运行的环境会影响配置加载、异常页面显示等行为。3. 构建一个完整的待办事项 API我们将构建一个简单的待办事项管理 API涵盖控制器、模型、服务层和内存数据存储以此演示 ASP.NET Core 的核心开发模式。3.1 定义数据模型与仓储接口首先在项目根目录创建Models文件夹并添加TodoItem.cs// Models/TodoItem.cs namespace MyAspNetCoreApi.Models; public class TodoItem { public int Id { get; set; } public string? Title { get; set; } public bool IsCompleted { get; set; } public DateTime CreatedAt { get; set; } DateTime.UtcNow; }接着创建Services文件夹并定义仓储层的抽象接口ITodoRepository.cs// Services/ITodoRepository.cs using MyAspNetCoreApi.Models; namespace MyAspNetCoreApi.Services; public interface ITodoRepository { IEnumerableTodoItem GetAll(); TodoItem? GetById(int id); TodoItem Add(TodoItem item); bool Update(TodoItem item); bool Delete(int id); }3.2 实现内存仓储与服务注册实现一个基于内存列表的仓储。在Services文件夹下创建InMemoryTodoRepository.cs// Services/InMemoryTodoRepository.cs using MyAspNetCoreApi.Models; namespace MyAspNetCoreApi.Services; public class InMemoryTodoRepository : ITodoRepository { private readonly ListTodoItem _items new(); private int _nextId 1; public IEnumerableTodoItem GetAll() _items; public TodoItem? GetById(int id) _items.FirstOrDefault(i i.Id id); public TodoItem Add(TodoItem item) { item.Id _nextId; _items.Add(item); return item; } public bool Update(TodoItem updatedItem) { var index _items.FindIndex(i i.Id updatedItem.Id); if (index 0) return false; _items[index] updatedItem; return true; } public bool Delete(int id) { var item GetById(id); if (item null) return false; return _items.Remove(item); } }现在需要在Program.cs中将此服务注册到依赖注入容器。由于仓储通常与 HTTP 请求关联每个请求一个独立的仓储实例是安全的我们使用作用域生命周期。在Program.cs的builder.Services配置部分添加builder.Services.AddScopedITodoRepository, InMemoryTodoRepository();3.3 创建 API 控制器在Controllers文件夹下创建TodoController.cs。ASP.NET Core 通过特性路由和模型绑定简化了 Web API 的创建。// Controllers/TodoController.cs using Microsoft.AspNetCore.Mvc; using MyAspNetCoreApi.Models; using MyAspNetCoreApi.Services; namespace MyAspNetCoreApi.Controllers; [ApiController] [Route(api/[controller])] // 路由模板访问路径为 /api/todo public class TodoController : ControllerBase { private readonly ITodoRepository _repository; // 依赖注入构造函数注入 ITodoRepository public TodoController(ITodoRepository repository) { _repository repository; } // GET: api/todo [HttpGet] public ActionResultIEnumerableTodoItem GetAll() { return Ok(_repository.GetAll()); } // GET: api/todo/5 [HttpGet({id})] public ActionResultTodoItem GetById(int id) { var item _repository.GetById(id); if (item null) { return NotFound(); // 返回 404 状态码 } return Ok(item); } // POST: api/todo [HttpPost] public ActionResultTodoItem Create(TodoItem item) { // 模型验证自动进行如果 item 无效会返回 400 Bad Request var createdItem _repository.Add(item); // 返回 201 Created 状态码并在 Location 头中提供新资源的 URI return CreatedAtAction(nameof(GetById), new { id createdItem.Id }, createdItem); } // PUT: api/todo/5 [HttpPut({id})] public IActionResult Update(int id, TodoItem item) { if (id ! item.Id) { return BadRequest(); // 返回 400 状态码 } if (!_repository.Update(item)) { return NotFound(); } return NoContent(); // 返回 204 No Content 状态码 } // DELETE: api/todo/5 [HttpDelete({id})] public IActionResult Delete(int id) { if (!_repository.Delete(id)) { return NotFound(); } return NoContent(); } }3.4 运行与验证 API在项目根目录运行以下命令启动应用dotnet run应用启动后默认会监听http://localhost:5193和https://localhost:7193端口可能不同。打开浏览器或使用工具访问Swagger UI访问https://localhost:7193/swagger这是一个交互式的 API 文档界面可以直接测试所有端点。直接调用 API使用 curl 或 Postman。获取所有待办事项GET https://localhost:7193/api/todo创建新待办事项POST https://localhost:7193/api/todoBody 为 JSON{title: 学习 ASP.NET Core, isCompleted: false}观察控制台输出可以看到 Kestrel 服务器的启动日志和请求处理日志。4. 配置、日志与异常处理进阶一个健壮的应用离不开完善的配置、日志和异常处理机制。4.1 多环境配置管理ASP.NET Core 支持基于环境的配置。配置文件按以下顺序加载后面的覆盖前面的appsettings.jsonappsettings.{Environment}.json(例如appsettings.Development.json)环境变量命令行参数创建appsettings.Production.json文件覆盖生产环境的日志级别并添加数据库连接字符串{ Logging: { LogLevel: { Default: Warning, Microsoft.AspNetCore: Warning } }, ConnectionStrings: { DefaultConnection: Serverprod-db-server;DatabaseMyAppDb;Trusted_Connectionfalse;User Idsa;Passwordyour_strong_password; } }在代码中可以通过IConfiguration接口读取配置。例如在Program.cs中读取连接字符串var connectionString builder.Configuration.GetConnectionString(DefaultConnection);4.2 结构化日志与 Serilog 集成虽然内置日志提供程序功能齐全但生产环境更推荐使用结构化日志系统如Serilog。它可以将日志输出为 JSON 格式便于被 ELK、Seq 等日志系统收集和分析。首先安装 NuGet 包dotnet add package Serilog.AspNetCore dotnet add package Serilog.Sinks.Console dotnet add package Serilog.Sinks.File在Program.cs的最开始配置 Serilogusing Serilog; Log.Logger new LoggerConfiguration() .MinimumLevel.Information() .WriteTo.Console(outputTemplate: [{Timestamp:HH:mm:ss} {Level:u3}] {Message:lj}{NewLine}{Exception}) .WriteTo.File(logs/myapp-.txt, rollingInterval: RollingInterval.Day) .CreateLogger(); try { var builder WebApplication.CreateBuilder(args); // 使用 Serilog 替换默认日志提供程序 builder.Host.UseSerilog(); // ... 其余服务配置 } catch (Exception ex) { Log.Fatal(ex, Application startup failed); } finally { Log.CloseAndFlush(); }在控制器或服务中通过依赖注入ILoggerT来记录日志public class TodoController : ControllerBase { private readonly ITodoRepository _repository; private readonly ILoggerTodoController _logger; public TodoController(ITodoRepository repository, ILoggerTodoController logger) { _repository repository; _logger logger; } [HttpGet({id})] public ActionResultTodoItem GetById(int id) { _logger.LogInformation(Getting todo item with ID {TodoId}, id); // 结构化日志 var item _repository.GetById(id); if (item null) { _logger.LogWarning(Todo item with ID {TodoId} not found, id); return NotFound(); } return Ok(item); } }4.3 全局异常处理与问题详情在开发环境UseDeveloperExceptionPage中间件可以提供详细的异常信息。但在生产环境我们需要一个更友好、更安全的全局异常处理机制。ASP.NET Core 提供了UseExceptionHandler中间件。我们可以创建一个专用的错误处理控制器// Controllers/ErrorController.cs using Microsoft.AspNetCore.Diagnostics; using Microsoft.AspNetCore.Mvc; namespace MyAspNetCoreApi.Controllers; [ApiController] [Route(/error)] [ApiExplorerSettings(IgnoreApi true)] // 从 Swagger 文档中隐藏 public class ErrorController : ControllerBase { [HttpGet] [HttpPost] [HttpPut] [HttpDelete] public IActionResult HandleError() { var exceptionHandlerFeature HttpContext.Features.GetIExceptionHandlerFeature(); var exception exceptionHandlerFeature?.Error; // 生产环境记录异常返回通用错误信息 // 开发环境可以返回更多细节需谨慎 var problemDetails new ProblemDetails { Status StatusCodes.Status500InternalServerError, Title An error occurred while processing your request., Detail exception?.Message // 生产环境通常不返回此信息 }; return StatusCode(StatusCodes.Status500InternalServerError, problemDetails); } }在Program.cs的管道配置中在管道顶部添加异常处理if (!app.Environment.IsDevelopment()) { app.UseExceptionHandler(/error); // 生产环境也建议启用严格的 HTTP 安全头 app.UseHsts(); } else { app.UseDeveloperExceptionPage(); }5. 生产环境部署与性能考量将应用部署到生产环境时需要考虑性能、安全性和可维护性。5.1 发布应用使用 .NET CLI 发布应用为自包含或框架依赖的部署。# 发布为框架依赖目标机器需安装对应运行时 dotnet publish -c Release -o ./publish # 发布为自包含将运行时打包进去体积更大 dotnet publish -c Release -r linux-x64 --self-contained true -o ./publish-linux-c Release指定使用发布配置这会启用代码优化。5.2 使用反向代理在生产环境中通常不直接对外暴露 Kestrel。而是使用反向代理服务器如 Nginx, Apache, IIS来处理静态文件、SSL 终止、负载均衡等再将请求转发给 Kestrel。一个简单的 Nginx 配置示例 (/etc/nginx/sites-available/myapp)server { listen 80; server_name yourdomain.com; location / { proxy_pass http://localhost:5000; # Kestrel 监听地址 proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection keep-alive; proxy_set_header Host $host; proxy_cache_bypass $http_upgrade; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }注意确保 Kestrel 配置appsettings.json或Program.cs中的applicationUrl与反向代理的转发地址一致并正确配置ForwardedHeaders中间件以使应用能识别原始请求信息。5.3 性能优化建议异步编程尽可能使用async/await处理 I/O 密集型操作如数据库查询、HTTP 调用避免阻塞线程池线程。public async TaskActionResultIEnumerableTodoItem GetAllAsync() { var items await _repository.GetAllAsync(); // 假设仓储有异步方法 return Ok(items); }响应缓存对于不常变化的数据使用[ResponseCache]特性或内存缓存来减少计算和数据库压力。数据库连接池使用DbContext时EF Core 默认管理连接池。确保在appsettings.json中正确配置连接字符串。健康检查添加健康检查端点便于容器编排平台监控应用状态。dotnet add package Microsoft.AspNetCore.Diagnostics.HealthChecksbuilder.Services.AddHealthChecks(); app.MapHealthChecks(/health);6. 常见问题排查清单在开发部署过程中你可能会遇到以下问题。这里提供一份排查清单。问题现象可能原因检查步骤与解决方案dotnet run失败提示 SDK 未找到.NET SDK 未安装或未添加到 PATH 环境变量。1. 运行dotnet --version确认安装。2. 检查系统环境变量 PATH 是否包含 SDK 路径。应用启动后立即退出端口被占用或Program.cs中的app.Run()之前提前返回。1. 检查控制台错误信息。2. 使用netstat -ano查看端口占用。3. 确保app.Run()是Program.cs的最后一行。API 返回 404路由不匹配或控制器未正确注册。1. 检查控制器[Route]特性和 HTTP 方法特性。2. 确认Program.cs中调用了app.MapControllers()。3. 检查请求的 URL 和 HTTP 方法是否正确。依赖注入服务解析失败服务未注册或生命周期不匹配。1. 检查Program.cs中是否注册了该服务。2. 确认注册的生命周期Scoped/Transient/Singleton与使用场景匹配。3. 尝试在构造函数中注入而不是在方法内手动从容器解析。配置值读取为null配置键名错误或配置文件未加载。1. 使用builder.Configuration.AsEnumerable()输出所有配置项检查。2. 确认appsettings.{Environment}.json文件名和环境变量ASPNETCORE_ENVIRONMENT设置正确。3. 检查 JSON 文件格式是否正确。数据库连接失败连接字符串错误、数据库服务未启动或网络不通。1. 在Program.cs启动时打印连接字符串仅限开发环境进行核对。2. 使用数据库客户端工具测试连接。3. 检查数据库防火墙规则。静态文件无法访问未启用静态文件中间件或文件路径不正确。1. 确认Program.cs中调用了app.UseStaticFiles()。2. 静态文件应放在wwwroot目录下或使用UseStaticFiles重载指定自定义目录。Swagger 页面无法打开未注册 Swagger 服务或未启用中间件。1. 检查builder.Services.AddSwaggerGen()和app.UseSwagger()、app.UseSwaggerUI()是否已添加。2. 确认仅在开发环境启用或生产环境有相应安全措施。掌握 ASP.NET Core 不仅在于能运行一个示例项目更在于理解其管道模型、依赖注入哲学以及如何根据环境配置应用。从简单的内存存储切换到真正的数据库从开发环境切换到生产部署每一步都需要仔细考虑配置、日志和异常处理。建议在掌握本文内容后进一步探索真实数据库集成、身份认证与授权、单元测试与集成测试以及利用 Docker 容器化部署从而构建出更健壮、可维护的企业级应用。