选错模板应立即删除重建：Web API 用 dotnet new webapi，最小API用 dotnet new web，MVC项目用 dotnet new mvc；共存 Startup.cs 和 Program.cs 时仅后者生效，须迁移注册逻辑；404多因中间件顺序错误或控制器命名不符；IIS 500.19 错误主因是未安装对应 Hosting Bundle 或 web.config 配置不当。
dotnet new 命令创建项目时选错模板怎么办
直接用 dotnet new 创建 ASP.NET Core 项目，最容易出错的是模板类型选错——比如想建 Web API 却用了 web（带 Razor 页面的全栈模板），或者想建最小 API 却用了 webapi（传统控制器模板）。这会导致后续引用冗余、路由行为不一致，甚至 Program.cs 结构完全对不上。
正确做法是明确目标后精准选模板：
- 纯 HTTP 接口服务（无视图）：用
dotnet new webapi -n MyApi - 极简无控制器的端点服务：用
dotnet new web -n MyMinimal（.NET 6+ 默认就是 Minimal Hosting Model） - 需要 Razor 页面和 MVC 的后台管理类项目：用
dotnet new mvc -n MyAdmin
注意：web 模板从 .NET 6 开始默认启用 Minimal Hosting，而 webapi 仍保留 Startup.cs 风格（除非加 --use-program-main 参数强制切换）。模板差异直接影响中间件注册方式和配置加载时机。
Startup.cs 和 Program.cs 共存时为什么注入失败
常见于从旧项目升级或手动合并代码后，项目里同时存在 Startup.cs 和 Program.cs。此时 ASP.NET Core 运行时只会识别其中一个入口——.NET 6+ 默认只认 Program.cs 中的 WebApplicationBuilder，Startup 类会被完全忽略，导致你写的 ConfigureServices 里的 services.AddXxx() 一句都没执行。
检查方法很简单：在 Program.cs 顶部加一行 Console.WriteLine("Program.cs loaded");，再在 Startup.ConfigureServices 里也加打印。运行后只看到前者，就确认 Startup 已失效。
解决方案只有两个：
- 彻底删除
Startup.cs，把所有注册逻辑迁入Program.cs的builder.Services链式调用中 - 如果必须保留
Startup（如团队强依赖旧结构），需在Program.cs中显式调用它：var builder = WebApplication.CreateBuilder(args); var startup = new Startup(builder.Configuration); startup.ConfigureServices(builder.Services);——但这是反模式，不推荐
Controller 返回 404 但路由看起来写对了
典型现象：访问 /weatherforecast 返回 404，可 WeatherForecastController 明明有 [ApiController] 和 [Route("api/[controller]")]，连 Swagger 都能列出这个接口。
根本原因往往不是路由写错，而是中间件顺序问题。ASP.NET Core 要求 UseRouting() 必须在 UseEndpoints() 或 MapControllers() 之前，且不能被其他中间件（尤其是自定义异常处理或静态文件中间件）意外拦截。
检查 Program.cs 中的中间件注册顺序，确保类似这样：
app.UseRouting(); app.UseAuthentication(); // 如需认证 app.UseAuthorization(); app.MapControllers(); // 必须在 UseRouting 之后、UseEndpoints 之前
另外注意：若控制器类名不含 Controller 后缀（比如叫 WeatherForecast 而非 WeatherForecastController），即使加了 [Route] 也不会被自动发现——MVC 的控制器发现机制严格依赖命名约定。
开发环境能跑，发布到 IIS 就 500.19 错误
HTTP Error 500.19 - Internal Server Error + 错误代码 0x8007000d，基本锁定为 IIS 模块缺失或 web.config 配置错误。这不是代码问题，而是部署环境没对齐。
关键检查点：
- 目标服务器是否安装了对应版本的
ASP.NET Core Runtime Hosting Bundle（不是 SDK）？例如 .NET 8 项目必须装 .NET 8 Hosting Bundle，装错版本或只装 SDK 都会失败 -
web.config是否由dotnet publish自动生成？手写或复制旧项目的容易漏掉<aspnetcore processpath="dotnet" arguments=".\MyApp.dll" ...></aspnetcore>这段，或stdoutLogEnabled设为 true 却没建logs目录 - IIS 应用池“托管管道模式”必须设为
Integrated，且“.NET CLR 版本”设为No Managed Code
最快速验证方式：进服务器命令行，cd 到发布目录，直接运行 dotnet MyApp.dll。如果能启动并响应 HTTP 请求，说明程序本身没问题，问题 100% 出在 IIS 配置或 Hosting Bundle 上。
复杂点在于错误日志默认不输出——务必在 web.config 里打开 stdout 日志，并确保 logs 目录有 IIS_IUSRS 写权限，否则连具体哪行报错都看不到。
