因为 ASP.NET Core 是当前 C# Web 开发唯一兼具性能、跨平台、可维护性与长期支持的现代框架。 它不是“升级选项”，而是 .NET 生态中已事实取代传统 ASP.NET 和 .NET Framework Web 技术的主力栈。
为什么 Kestrel + 中间件模型让请求处理快 2–3 倍
传统 ASP.NET（基于 IIS + Http.sys）在 Windows 上有大量隐式管道步骤（如 Session 初始化、Module 加载），即使你不用，它也执行。ASP.NET Core 默认用
Kestrel作为跨平台 HTTP 服务器，并通过显式注册的
middleware处理请求——没有冗余环节，每个中间件只做一件事。 实测：同等硬件下，ASP.NET Core 的吞吐量通常是 ASP.NET MVC（.NET Framework）的
2300%（官方基准测试数据） 典型错误：把
Kestrel直接暴露到公网 —— 它不是反向代理，生产环境必须前置
Nginx或
IIS，否则会丢连接或无法处理 TLS 终止 性能关键点：
app.UseRouting()和
app.UseEndpoints()的顺序不能颠倒，否则路由不生效，返回 404 却无日志提示
为什么依赖注入（DI）不再是“高级技巧”，而是每天写代码的基础
在 ASP.NET Core 中，
IServiceCollection是启动时的“服务注册中心”，控制器、页面、后台服务甚至中间件都能自动接收依赖 —— 这不是语法糖，是强制解耦的设计约束。 常见坑：
AddScoped在中间件里直接 new 实例会导致生命周期错乱；必须通过
HttpContext.RequestServices.GetService<t>()</t>获取 场景差异：
AddSingleton适合无状态工具类；
AddScoped对应一次 HTTP 请求（如 EF Core 的
DbContext）；
AddTransient每次调用都新建，慎用于重量对象 调试技巧：启动失败报
Unable to resolve service for type 'X' while attempting to activate 'Y'？说明你忘了在
ConfigureServices里注册
X
为什么 Razor Pages / Blazor / MVC 不是“选一个”，而是按需混用
ASP.NET Core 不强制你押注单一 UI 范式。你可以用
Razor Pages快速交付管理后台，用
Blazor Server做实时表单交互，再用
Minimal API暴露数据接口 —— 全部跑在一个项目里，共享
DbContext、验证逻辑、中间件和 DI 容器。 Razor Pages 适合 CRUD 密集型页面：每个
.cshtml.cs文件自带
OnGet/
OnPost，比 MVC 少一层控制器跳转 Blazor WebAssembly 仍需注意：
HttpClient默认不能跨域，调后端 API 需配
Cors，且首次加载 wasm 包较大（建议启用压缩和 CDN 缓存） 别踩的坑：在
Program.cs启用
AddRazorPages()后，忘了加
app.MapRazorPages()，结果所有
.cshtml页面 404
真正容易被忽略的是：ASP.NET Core 的“轻量”不是靠删功能，而是靠模块化裁剪 —— 你不用 SignalR 就不引用
Microsoft.AspNetCore.SignalR，不用 Identity 就不装
Microsoft.AspNetCore.Identity。这种可控性，在旧框架里根本不存在。项目越往后演进，这个设计就越省心。
