<p>ASP.NET Core 是当前 C# Web 开发唯一兼具性能、跨平台、可维护性与长期支持的现代框架，已事实取代传统 ASP.NET 和 .NET Framework Web 技术。</p>
因为 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 是启动时的“服务注册中心”，控制器、页面、后台服务甚至中间件都能自动接收依赖 —— 这不是语法糖，是强制解耦的设计约束。
使用 Playwright 为 jimeng.jianying.com 管理浏览器会话，导入 cookies/localStorage 以自动化视频生成工作流，支持图片上传等功能
- 常见坑：
AddScoped在中间件里直接 new 实例会导致生命周期错乱；必须通过HttpContext.RequestServices.GetService<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。这种可控性，在旧框架里根本不存在。项目越往后演进，这个设计就越省心。
