这种情况我之前在排查ASP.NET Core项目时碰到过类似的，给你整理几个实用的排查步骤，一步步来应该能定位到问题：

• 先盯紧路由配置，这是最常见的坑
  先去Startup.cs的Configure方法里确认：有没有正确注册MVC路由中间件？比如是不是写了app.UseMvc(routes => { ... })或者UseMvcWithDefaultRoute()？另外，控制器上的[Route]属性有没有写错？比如路由模板里的参数和请求URL不匹配，或者控制器类忘了加[ApiController]/[Controller]属性——没加的话路由系统根本识别不到这个控制器。

• 检查中间件执行顺序，别让中间件“抢了先”
  ASP.NET Core中间件是按注册顺序执行的，如果你在UseMvc()前面加了自定义中间件，一定要确认它有没有正确调用await next(context)。要是某个中间件没传递请求，直接返回了，那请求到不了MVC中间件，自然就404了。也可以先把自定义中间件暂时注释掉，只保留UseStaticFiles()、UseMvc()这些基础中间件，看看请求能不能正常响应，排除自定义中间件的干扰。

• 开详细日志，看请求到底走到哪一步了
  把appsettings.json里的日志级别调细，比如：

  {
    "Logging": {
      "LogLevel": {
        "Microsoft.AspNetCore": "Debug",
        "Microsoft.AspNetCore.Routing": "Trace"
      }
    }
  }
  

  启动应用后用Postman发请求，然后看日志里的路由匹配过程——日志会明确告诉你请求是匹配到了路由，还是根本没找到对应路由。比如出现“No routes matched the request”说明路由阶段就挂了，要是有“Route matched with {routeName}”但还是404，那就要看控制器Action是不是有问题了。

• 检查控制器和Action的基础配置
  别忽略最基础的点：控制器类和Action方法是不是public的？如果是private或者protected，MVC是不会调用的。另外，Action的参数是不是和请求匹配？比如GET请求的参数有没有加[FromQuery]，POST的有没有加[FromBody]？参数不匹配有时候也会导致找不到Action，返回404。

• 验证异常处理中间件的影响
  你说异常能被正常识别，那看看UseExceptionHandler()是不是注册在UseMvc()前面？虽然正常来说这不会影响正常请求，但如果异常处理中间件里有逻辑错误，比如不小心在正常请求路径里返回了404，那就麻烦了。可以暂时移除异常处理中间件，测试正常请求是否能响应。

• 排查部署环境的问题（如果是部署到服务器的话）
  要是部署到IIS，先确认应用程序池是不是.NET Core模式，不能用经典模式。再检查web.config里的aspNetCore节点，processPath是不是指向正确的dotnet命令或者发布后的exe文件。另外，试试本地发布后直接运行发布的文件，看看会不会出现同样的问题——如果本地正常，部署后出问题，那大概率是服务器环境配置的问题。

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