ASP.NET Core中的路由系统，说白了，就是你的应用如何理解和响应用户在浏览器地址栏里输入的网址（URL）的机制。它像一个智能的交通指挥官，负责把每一个进来的HTTP请求，准确无误地导向你代码里对应的处理逻辑，比如一个控制器里的某个动作方法，或者一个Minimal API的终结点。没有它，你的应用就不知道该怎么处理各种请求，简直寸步难行。
解决方案
在ASP.NET Core里定义路由，通常会在应用的启动配置（
Program.cs或
Startup.cs）里完成。核心是引入
app.UseRouting()和
app.UseEndpoints()这两个中间件。
UseRouting()负责路由匹配，而
UseEndpoints()则执行匹配到的终结点。
1. 控制器（Controller）路由： 这是传统MVC应用中最常见的定义方式，分为两种：
约定式路由（Conventional Routing）： 通过预设的模式来匹配URL。你可以在
Program.cs（或
Startup.cs的
Configure方法）中定义：
app.UseEndpoints(endpoints =>
{
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
// 你可以定义更多特定的约定式路由
// endpoints.MapControllerRoute(
// name: "blog",
// pattern: "blog/{articleId}",
// defaults: new { controller = "Blog", action = "Article" });
});这个
default路由模式意味着URL通常是
/控制器名/动作方法名/可选的ID。比如
/Home/Index。
特性路由（Attribute Routing）： 将路由规则直接写在控制器类或动作方法上，这在我看来，是定义RESTful API时最清晰、最直观的方式。
[ApiController]
[Route("api/[controller]")] // 类级别路由前缀
public class ProductsController : ControllerBase
{
[HttpGet] // 匹配GET请求到 api/Products
public IActionResult GetProducts()
{
return Ok(new[] { "Product A", "Product B" });
}
[HttpGet("{id}")] // 匹配GET请求到 api/Products/{id}
public IActionResult GetProduct(int id)
{
// ...
return Ok($"Product {id}");
}
[HttpPost("add")] // 匹配POST请求到 api/Products/add
public IActionResult AddProduct([FromBody] string productName)
{
// ...
return CreatedAtAction(nameof(GetProduct), new { id = 1 }, productName);
}
}特性路由的优先级通常高于约定式路由，也更灵活，特别适合构建清晰的API接口。
2. Minimal API 路由： 这是.NET 6引入的新范式，特别适合构建轻量级、高性能的微服务或小型API。路由直接定义在
Program.cs里，与处理逻辑紧密结合。
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();
app.UseRouting(); // 仍然需要路由中间件
app.UseEndpoints(endpoints =>
{
endpoints.MapGet("/", () => "Hello World!"); // 匹配GET /
endpoints.MapGet("/users/{id}", (int id) => $"User ID: {id}"); // 匹配GET /users/{id}
endpoints.MapPost("/items", (string item) => Results.Ok($"Created item: {item}")); // 匹配POST /items
});
app.Run();Minimal API的路由定义非常简洁，没有控制器和动作方法的概念，直接将URL映射到Lambda表达式或本地函数。
无论哪种方式，路由的定义顺序在某些情况下很重要，尤其是当有重叠的路由模式时，更具体的路由应该放在更通用的路由之前。
ASP.NET Core路由与传统Web Forms或MVC有何不同？
这真是一个好问题，尤其对于那些从旧框架迁移过来的开发者来说。在我看来，ASP.NET Core的路由系统，相较于传统的ASP.NET Web Forms或早期的ASP.NET MVC，最大的不同在于其灵活性、模块化和对“终结点路由”（Endpoint Routing）的彻底拥抱。
首先，Web Forms基本上没有我们现在意义上的路由，它更多是基于物理文件路径来处理请求，通过URL重写（URL Rewriting）才能模拟出“干净”的URL，这在当时显得有些笨重。而ASP.NET MVC虽然引入了路由概念，比如在
RouteConfig.cs里定义路由表，但它本质上还是紧密绑定到控制器和动作方法。
ASP.NET Core则更进一步，引入了终结点路由。这意味着路由系统不再仅仅是为了找到一个控制器动作，它可以找到任何可以作为“终结点”的东西——一个控制器动作、一个Razor Page、一个SignalR Hub，甚至是一个Minimal API的Lambda表达式。这种设计让整个框架的耦合度大大降低，你可以根据需要选择不同的处理方式，而路由系统依然能统一调度。
我个人觉得，最直观的感受是，在ASP.NET Core里，路由的配置变得更加声明式。无论是特性路由直接写在代码旁边，还是Minimal API直接将路由和处理逻辑写在一起，都比以前那种集中式的路由表配置更贴近代码本身。这种变化，让路由的意图更明确，维护起来也更方便，尤其是在大型项目中，不同模块的路由可以独立定义，减少了冲突的可能性。此外，ASP.NET Core的路由是作为中间件集成进请求管道的，这意味着它可以与其他中间件（如认证、授权）无缝协作，提供了更强大的扩展性。
在ASP.NET Core中，如何选择适合的路由定义方式？
选择合适的路由定义方式，其实是根据你的项目类型、团队习惯和对代码组织的需求来决定的。这没有绝对的对错，更多是一种权衡。
如果你的项目是一个传统的MVC应用，需要渲染HTML视图，并且控制器和动作方法比较多，那么约定式路由仍然是一个非常实用的选择。它能让你用最少的配置覆盖大量的URL模式，比如
/Products/List、
/Users/Details/5等，非常适合那些遵循标准MVC模式的应用。它的缺点是，当URL模式变得复杂或需要特别定制时，约定式路由可能会显得不够灵活，需要你手动添加更多的
MapControllerRoute。
对于构建RESTful API，或者需要细粒度控制每个终结点URL的场景，我强烈推荐特性路由。在我看来，它就是为API而生的。你可以在控制器或动作方法上直接用
[Route]、
[HttpGet]等特性来定义URL，这让API的URL结构与代码结构紧密结合，可读性极高。当一个开发者看到一个API方法时，几乎立刻就能知道它的URL路径和HTTP动词。这对于维护和理解大型API项目至关重要。我个人在使用特性路由时，会尽量让URL路径反映资源的层级关系，这能让API设计更加清晰。
而Minimal API，则是为轻量级、高性能的微服务或小型工具API量身定制的。如果你只是需要快速搭建几个简单的HTTP终结点，或者构建一个无视图的后端服务，Minimal API无疑是最佳选择。它省去了控制器、动作方法、甚至
Startup.cs的繁琐配置，直接在
Program.cs里完成所有事情。这使得开发效率极高，代码量也大大减少。但如果你的应用逻辑非常复杂，或者需要大量的依赖注入、过滤器等高级功能，那么Minimal API可能会让
Program.cs变得臃肿，这时候控制器或更传统的MVC模式可能更合适。
简单来说，如果追求约定大于配置，且是MVC应用，选约定式路由；如果追求明确的URL结构和API设计，特别是RESTful服务，选特性路由；如果追求极致的简洁和开发效率，且是小型API，选Minimal API。很多时候，在一个项目中，你甚至会混合使用这些方式，比如MVC应用用约定式路由，但其中一些API部分则使用特性路由。
处理复杂的路由场景，如路由参数、约束与回退路由，有哪些技巧？
处理复杂的路由场景，是真正考验你对ASP.NET Core路由系统理解深度的地方。这不仅仅是定义一个简单的URL，更是要让路由系统能够智能地解析各种输入，并做出正确的响应。
1. 路由参数与可选参数： 路由参数是URL中的占位符，用来捕获URL中的动态值。比如
/products/{id}中的{id}。
基本参数： endpoints.MapControllerRoute(..., pattern: "{controller}/{action}/{id}")
可选参数： 通过在参数名后加?来表示，例如
{id?}。这意味着URL中可以有这个参数，也可以没有。这在很多场景下非常有用，比如一个分页列表，page参数可能存在也可能不存在。
2. 路由约束（Route Constraints）： 路由约束是用来限制路由参数必须符合特定格式的规则。这能有效避免歧义路由，并提供更好的URL解析。
内置约束： ASP.NET Core提供了许多内置约束，比如：
{id:int}：id必须是整数。
{name:alpha}：name必须只包含字母。
{slug:minlength(5)}：slug最小长度为5。
{date:datetime}：date必须是日期时间格式。
{zipcode:regex(^[0-9]{5}$)}：使用正则表达式匹配美国邮政编码。
这些约束可以直接加在路由参数后面，例如：
[HttpGet("products/{id:int}")] // id必须是整数
public IActionResult GetProductById(int id) { /* ... */ }
[HttpGet("blog/{year:int}/{month:int}/{slug:minlength(10)}")] // 多个约束 public IActionResult GetBlogPost(int year, int month, string slug) { / ... / }
使用约束能让路由匹配更精确，避免一个URL意外匹配到错误的动作。
3. 默认值： 你可以为路由参数设置默认值，当URL中缺少该参数时，就会使用默认值。
endpoints.MapControllerRoute(
name: "products",
pattern: "products/{action=List}/{id?}", // action默认为List
defaults: new { controller = "Products" });这样，访问
/products就会等同于
/Products/List。
4. 回退路由（Fallback Routes）： 回退路由是一个非常实用的机制，它定义了一个“万能”的路由，当所有其他路由都无法匹配时，就会使用它。这在单页应用（SPA）中尤其常见，因为SPA的路由通常由前端JavaScript处理。
MapFallbackToController
/ MapFallbackToPage
：
app.UseEndpoints(endpoints =>
{
// 其他正常的路由定义
endpoints.MapControllerRoute(
name: "default",
pattern: "{controller=Home}/{action=Index}/{id?}");
// 回退路由，将所有未匹配的请求导向Home控制器的Index动作
endpoints.MapFallbackToController("Index", "Home");
});当用户直接访问
/some/nonexistent/path时，如果前端路由没有处理，服务器就会将请求导向
Home/Index，让SPA的根页面加载，再由前端路由接管。
MapFallbackToFile
：
app.UseStaticFiles(); // 确保静态文件中间件在回退路由之前
app.UseRouting();
app.UseEndpoints(endpoints =>
{
// ... 其他API或MVC路由
endpoints.MapFallbackToFile("index.html"); // 将所有未匹配的请求导向wwwroot/index.html
});这在部署SPA时非常常见，它确保无论用户访问什么路径，都能加载SPA的
index.html文件，然后由前端框架（如React, Angular, Vue）来处理客户端路由。
这些技巧的灵活运用，能让你构建出既强大又健壮的路由系统，应对各种复杂的URL结构和请求模式。关键在于理解它们各自的用途和优先级，并根据实际需求进行组合。
