1.1 从ASP到ASP.NET Core的演进与选型

1.1 从 ASP 到 ASP.NET Core 的演进与选型

ASP.NET Core 是 2016 年微软对 ASP.NET 的彻底重写：跨平台、开源、模块化、高性能，不再是 .NET Framework 的附加组件，而是一套独立的、随 .NET 演进的 Web 框架。理解这段演进史，是避免在旧资料里迷路的第一步。

站在观察哨的位置说句实话：学 ASP.NET 最危险的不是难，而是学错年代的东西。搜索引擎里排名靠前的教程，相当一部分还在讲 Web Forms 的 ViewState、System.Web 命名空间、Global.asax——这些在 ASP.NET Core 里已经不存在了。这一节先把二十多年的技术线捋直，你会获得一种"年代鉴定"能力：看到一段代码，能立刻判断它是哪一代的产物、还值不值得学。

四个年代，四次换轨

ASP.NET 的历史可以切成四段，每一段的驱动力不同：

Web Forms 的思路是"假装没有 HTTP"：用 ViewState 把页面状态塞进隐藏字段，用回传事件模拟桌面程序的感觉。这在 2003 年是聪明的妥协，但代价是页面笨重、测试困难。MVC 把模型、视图、控制器分开，回到了 HTTP 的本源。Web API 则顺应了移动端与前后端分离的浪潮，让服务端专心产出数据。

真正的断代发生在 2016 年。.NET Framework 深度绑定 Windows——System.Web 这个巨型类库二十年的沉积让任何大手术都无从下手。微软选择另起炉灶：丢掉 System.Web，把框架重写成几十个可独立更新的 NuGet 包，管线用中间件组合，运行时交给跨平台的 .NET Core。ASP.NET Core 这个名字里的"Core"，指的正是这次从内核开始的重建。

重写带来的四个本质变化

这些变化贯穿本教程后面的所有章节，值得在这里先立个牌子。

第一，跨平台。Kestrel 成为内建的高性能 Web 服务器，应用不再依赖 IIS 的进程托管；IIS 退化为反向代理。Nginx、Apache、容器、systemd，都成了可选宿主。

第二，中间件管线取代了 HttpModule/HttpPageHandlerFactory 那套注册体系。以前的功能靠 web.config 声明，现在一切按代码顺序组装。第 2 章整章讲它。

第三，依赖注入成为一等公民。框架自带的 IServiceCollection 不再需要第三方容器就能用，控制器、中间件、后台服务的构造参数都由容器填充。

第四，统一的编程模型。MVC 与 Web API 在旧世界里是两套类型（Controller 与 ApiController），在 ASP.NET Core 里合并为一套——同一个控制器既能返回视图也能返回 JSON。

用一段代码感受"年代鉴定"。旧派 ASP.NET（.NET Framework 时代）的模块注册长这样：

<!-- 旧时代：在 web.config 里注册 HTTP 模块，框架按配置反射加载 -->
<system.webServer>
  <modules>
    <add name="MyModule" type="MyApp.RequestTimerModule, MyApp" />
  </modules>
</system.webServer>
<!-- 现实痛点：模块的执行顺序由注册顺序与生命周期事件决定，
     出问题时只能翻文档，代码里完全看不见 -->
​

现代 ASP.NET Core 里，同样的事在代码里按顺序写明：

// 现代写法：中间件按注册顺序依次执行，顺序即逻辑
var builder = WebApplication.CreateBuilder(args);
var app = builder.Build();

app.Use(async (context, next) =>
{
    // 进站计时：请求进入本站时记录起始时刻
    var sw = System.Diagnostics.Stopwatch.StartNew();
    await next();                       // 放行给下一站
    sw.Stop();
    // 出站回看：此时已拿到状态码，可记录本请求耗时
    Console.WriteLine($"{context.Request.Path} 耗时 {sw.ElapsedMilliseconds}ms，" +
                      $"状态码 {context.Response.StatusCode}");
});

app.MapGet("/", () => "观察哨就位");
app.Run();
​

对比很直观：配置文件里的隐式注册变成了肉眼可见的显式管线。这正是"观察哨"视角成立的前提——顺序写在代码里，你才观察得到。

版本演化全景

图 1.1-1 ASP.NET 技术线演化时间线

选型：新项目怎么选，旧资料怎么筛

掌握了年代线，选型就变成了几条可执行的判断。

新项目几乎无脑选 ASP.NET Core on .NET 8（或更新的 LTS）。剩下的选择是页面模型：多页服务端渲染选 Razor Pages（第 4 章），大型多视图应用或传统习惯选 MVC（第 3 章），纯后端接口选 Web API（第 6 章），富交互前端考虑配合前端框架或 Blazor。这些会在各章展开，此处先立框架。

筛资料的三条铁律：见到 web.config、System.Web、Global.asax、ViewState，这是 .NET Framework 时代内容，弃；见到 Startup 类与 Configure 方法分离的写法，是 .NET Core 2.x–5 风格，仍可用但注意 .NET 6 起最小 API 与 WebApplication 写法；见到 WebApplication.CreateBuilder，才是与 .NET 8 兼容的现代写法。

⚠️ 常见坑：把 ".NET Core 3.1" 的教程直接在 .NET 8 上照抄。大多数概念相通，但 3.1 已停止支持，个别包（如第三方 JSON 库的版本约束）会装不上。认准 .NET 6 以后的资料最省事。

问题：公司老系统是 Web Forms，还值得先学它吗？

不值得。Web Forms 人才需求已萎缩到纯维护场景。正确路径是先掌握 ASP.NET Core，再回头接手 Web Forms——有了现代框架的对照，旧系统的设计局限反而看得更清楚，迁移改造也更有方向。

本节要点回顾

• 断代点在 2016：ASP.NET Core 是重写而非升级，System.Web 及其生态整体作废；
• 四个动机：跨平台、性能、开源、模块化，解释了后面所有设计选择；
• 中间件 + 依赖注入是新旧两代最本质的编程模型差异；
• 年代鉴定三铁律：见 web.config/System.Web 弃，见独立 Startup 类警惕，见 CreateBuilder 放心；
• 新项目默认 .NET 8，页面模型按 Razor Pages / MVC / Web API 分流。