.NET Core 3.1新增Area中TagHelpers无法生成正确URL问题

针对你遇到的TagHelper无法生成正确URL的问题，不需要给新Area单独配置特殊的TagHelper内容，大概率是以下几个常见配置疏漏导致的，按顺序排查：

• 检查新Area的控制器特性
  新Area下的所有控制器类必须添加[Area("你的区域名称")]特性，比如你的Area叫Admin，控制器就要写成：

  [Area("Admin")]
  public class HomeController : Controller
  {
      // ...
  }
  

  这个特性是路由系统识别Area归属的关键，漏加的话TagHelper根本找不到对应的区域路由。

• 确认新Area的_ViewImports.cshtml配置
  新Area的Views文件夹下必须有_ViewImports.cshtml文件，里面要包含TagHelper的导入语句，确保和原有Area的配置一致：

  @addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers
  @addTagHelper *, 你的项目名称
  @using 你的项目名称
  @using 你的项目名称.Areas.你的区域名称
  

  如果缺少这个文件或者导入语句，TagHelper属性会被当成普通HTML属性，不会被解析。

• 验证路由配置的顺序
  在Startup.cs的UseEndpoints方法中，Area路由必须放在默认路由的前面，比如：

  app.UseEndpoints(endpoints =>
  {
      // 先配置Area路由
      endpoints.MapAreaControllerRoute(
          name: "AdminArea",
          areaName: "Admin",
          pattern: "Admin/{controller=Home}/{action=Index}/{id?}");
  
      // 再配置默认路由
      endpoints.MapControllerRoute(
          name: "default",
          pattern: "{controller=Home}/{action=Index}/{id?}");
  });
  

  路由匹配是按顺序来的，如果默认路由在前，会优先匹配非Area的控制器，导致Area的TagHelper生成错误URL。

• 检查TagHelper属性的拼写一致性
  确保asp-area的属性值和Area文件夹名、控制器上的[Area]特性名称完全一致（虽然Windows系统大小写不敏感，但Linux下是敏感的，建议统一大小写），比如不要出现asp-area="admin"但控制器特性是[Area("Admin")]的情况。

• 清理缓存重启项目
  有时候Visual Studio的编译缓存会导致TagHelper不生效，手动删除项目根目录下的bin和obj文件夹，然后重启VS并重新生成项目，很多时候能解决这类诡异的解析问题。

如果以上步骤都排查过还是有问题，可以检查一下新Area的视图是否放在正确的Areas/[AreaName]/Views/[ControllerName]路径下，视图的命名是否和Action对应。

内容的提问来源于stack exchange，提问作者Nick Fleetwood