ASP.NET Core 是当前 C# Web 开发唯一兼具性能、跨平台、可维护性与长期支持的现代框架，已事实取代传统 ASP.NET 和 .NET Framework Web 技术。
因为 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获取() - 场景差异：
AddSingleton适合无状态工具类；AddScoped对应一次 HTTP 请求（如 EF Core 的DbContext）；AddTransient每次调用都新建，慎用于重量对象 - 调试技巧：启动失败报
Unable to resolve service for type 'X' while attempting to activate 'Y'？说明你忘了在ConfigureServices里注册X
为什么 Razor Page
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。这种可控性，在旧框架里根本不存在。项目越往后演进，这个设计就越省心。
