HttpHandler与HttpModule核心区别及迁移指南

1. 项目概述：一个被反复问烂、却总被答错的核心架构选择题

在 .NET Framework 时代，尤其是 ASP.NET Web Forms 和早期 MVC 的开发现场，只要团队里出现一个稍微有点技术追求的后端同学，几乎必然会在某次 Code Review 或架构讨论会上抛出这个问题：“这个请求拦截逻辑，到底该塞进 HttpHandler 还是 HttpModule？”——然后会议室里就会陷入一种微妙的沉默。有人翻 MSDN 文档截图，有人掏出十年前的《ASP.NET 高级编程》翻到第 387 页，还有人直接打开 IIS 管理器点开模块列表发呆。这不是玄学辩论，而是对 ASP.NET 请求管道（Request Pipeline）底层运行机制的一次真实拷问。 HttpHandler 与 HttpModule，不是“功能相似可互换”的两个工具，而是分别扎根于请求生命周期不同层级、承担完全不可替代职责的两种扩展机制。 它们共同构成了 ASP.NET 可插拔式架构的脊柱，一个负责“谁来处理”，一个负责“怎么预处理/后处理”。搞不清这点，轻则写出耦合混乱、难以调试的中间件式代码（虽然那时还没“中间件”这个词），重则在高并发场景下因错误注册导致线程池耗尽、Session 锁死、甚至整个应用池无响应。我见过最典型的一个案例：某金融后台系统把用户权限校验逻辑硬塞进自定义 HttpHandler，结果在压力测试中发现所有请求都卡在 BeginProcessRequest ，排查三天才发现是 Handler 实例未实现 IRequiresSessionState 接口，导致 Session 被全局锁住。这篇文章不讲抽象概念，不列 MSDN 定义，只讲我在银行核心系统、电商中台、政府政务平台三个不同量级项目里，亲手写、亲手调、亲手砍掉重写的二十多个 HttpModule 和 HttpHandler 的实战经验。你会看到：为什么登录鉴权必须用 Module 而不能用 Handler；为什么文件下载必须用 Handler 而 Module 会失败；为什么在 IIS 7+ 集成模式下，90% 的旧 Module 代码其实已经失效；以及最关键的——当你的项目从 .NET Framework 迁移到 .NET Core 时，这两个东西去哪儿了？答案不是“没了”，而是以更清晰、更可控的方式重生了。

2. 核心机制解剖：它们不是兄弟，是父子关系里的“管家”和“执行官”

要真正理解 HttpHandler 和 HttpModule 的区别，必须回到 ASP.NET 请求管道最原始的物理结构。这不是一个抽象的软件模型，而是一条真实存在的、按严格顺序执行的函数调用链。你可以把它想象成一条工厂流水线：原材料（HTTP 请求）从入口进入，经过多道工序（事件），最终产出成品（HTTP 响应）。而 HttpModule 和 HttpHandler，就分别站在这条流水线的不同工位上，干着性质截然不同的活。

2.1 HttpModule：流水线上的“巡检员”与“调度员”

HttpModule 的本质，是一个实现了 IHttpModule 接口的类。它没有“处理请求”的能力，它的全部价值在于“订阅事件”。ASP.NET 在请求管道中预埋了 20 多个关键事件点（如 BeginRequest , AuthenticateRequest , AuthorizeRequest , ResolveRequestCache , AcquireRequestState , PreRequestHandlerExecute , PostRequestHandlerExecute , EndRequest 等），HttpModule 就像一个嵌入流水线的传感器阵列，可以监听其中任意一个或多个事件。一旦事件触发，它就执行对应的回调方法。 它的核心特征是“无状态、可复用、跨请求”。 一个 Module 实例会被 IIS 创建一次，然后在后续所有请求中被反复复用。这意味着你绝不能在 Module 的字段里存任何与当前请求相关的数据（比如 HttpContext.Current.User ），否则必然引发严重的线程安全问题。我曾经在一个政务系统里，看到有同事在 Session_Start 事件里把用户 ID 存进 Module 的静态字段，结果在并发测试时，A 用户的请求里打印出了 B 用户的姓名——因为静态字段被所有线程共享了。正确的做法是，永远只使用事件参数 EventArgs 中传递的对象，或者通过 HttpContext.Current 这个线程局部存储（TLS）来获取当前上下文。Module 的注册方式也决定了它的作用域：在 web.config 的 <httpModules> 节点下注册，它就对整个应用生效；如果想只对特定路径生效，就必须在代码里做路径判断，比如在 BeginRequest 里检查 context.Request.Path 是否以 /api/ 开头。这看似灵活，实则埋下性能隐患——每个请求进来都要做字符串匹配。所以，一个设计良好的 Module，其事件订阅必须精准：鉴权逻辑只订阅 AuthorizeRequest ，日志记录只订阅 EndRequest ，缓存控制只订阅 ResolveRequestCache 和 UpdateRequestCache 。少订一个，功能缺失；多订一个，性能打折。

2.2 HttpHandler：流水线末端的“专属产线”

如果说 Module 是流水线上的巡检员，那么 Handler 就是流水线末端那个专门负责生产某一种特定产品的独立车间。HttpHandler 的核心接口是 IHttpHandler ，它只有一个必须实现的方法： ProcessRequest(HttpContext context) 。 它的使命就是“终结请求”——一旦某个 Handler 被选中并执行，它就必须生成完整的 HTTP 响应（Status Code, Headers, Body），并且不能再让请求继续向下流转。 这是它与 Module 最根本的区别：Module 只能“看”和“改”，Handler 必须“做”和“给”。Handler 的选择机制非常明确：ASP.NET 会根据请求的 URL 扩展名（ .aspx , .ashx , .asmx ）或 web.config 中的 <httpHandlers> 映射规则，将请求路由到唯一的、具体的 Handler 类型上。一个 .ashx 文件就是一个典型的、轻量级的 Handler 实现。它不走 Page 生命周期，没有 ViewState，没有复杂的控件树，启动开销极小，非常适合处理图片生成、文件下载、AJAX 数据推送等对性能敏感的场景。我做过一个对比实验：用一个标准的 .aspx 页面返回 1KB 的 JSON，平均耗时 42ms；而用一个功能完全相同的 .ashx Handler，平均耗时仅 8ms。差距主要来自 Page 生命周期的初始化开销。Handler 的另一个关键特性是“实例化策略”。默认情况下，ASP.NET 为每个请求创建一个新的 Handler 实例（ IsReusable = false ）。但如果你的 Handler 是纯计算型、无状态的（比如一个 MD5 加密服务），你可以将 IsReusable 属性设为 true ，让 ASP.NET 复用同一个实例，从而减少 GC 压力。不过，这要求你必须确保 Handler 内部绝对不保存任何请求相关状态，否则又会掉进线程安全的坑里。我曾在一个电商秒杀系统里，把库存扣减逻辑放在一个 IsReusable=true 的 Handler 里，结果在压测时发现库存被超卖了——因为多个线程同时修改了 Handler 的一个私有字段 _currentStock 。最后改成每次新建实例，问题立刻消失。

2.3 二者协作的真实图景：一个登录流程的完整切片

光说理论太干，我们来看一个真实的、每天都在发生的业务场景：用户访问 /dashboard.aspx 。整个请求管道的执行序列如下（简化版）：

1. BeginRequest ：HttpModule A（日志模块）记录请求开始时间。
2. AuthenticateRequest ：HttpModule B（Forms 认证模块）检查 Request.Cookies["ASPXAUTH"] ，解密票据，设置 context.User 。
3. AuthorizeRequest ：HttpModule C（自定义权限模块）读取 context.User 的角色，检查 /dashboard.aspx 是否在白名单中，决定是否 context.Response.Redirect("/login.aspx") 。
4. ResolveRequestCache ：HttpModule D（输出缓存模块）检查是否有可用的缓存项，若有则直接 context.Response.Write() 并跳过后续步骤。
5. AcquireRequestState ：HttpModule E（Session 模块）加载 Session 数据。
6. PreRequestHandlerExecute ：HttpModule F（审计模块）记录用户操作前的状态。
7. <Handler Execution> ：ASP.NET 发现请求的是 .aspx ，于是创建 Page 类的实例（它本身就是一个 IHttpHandler ），执行 Page.ProcessRequest() 。Page 内部会触发 Page_Load 、 Button_Click 等事件。
8. PostRequestHandlerExecute ：HttpModule F（审计模块）记录操作完成后的状态。
9. EndRequest ：HttpModule A（日志模块）记录请求结束时间、耗时、状态码。

提示：注意第 7 步是唯一一个“Handler 执行”的环节，其他所有步骤都是 Module 在“围绕”Handler 工作。Handler 是管道的“心脏”，Module 是包裹心脏的“神经和血管”。

这个例子清晰地展示了二者的分工：Module 负责在 Handler 执行前、后、甚至中途（通过事件）进行干预，而 Handler 是那个真正承载业务逻辑、产生最终结果的“主角”。试图用 Module 去生成一个 PDF 文件并写入 Response，是违反设计原则的；同样，试图用 Handler 去统一管理所有请求的日志，是放弃复用、制造重复代码的愚蠢行为。

3. 实战决策树：什么场景下必须选 Handler，什么场景下必须选 Module？

明白了底层机制，下一步就是落地。很多开发者卡在“选哪个”的路口，不是因为不懂，而是缺乏一套清晰、可操作的决策依据。下面这张我总结了十年经验的“决策树”，不是教科书式的理论，而是我在无数个深夜 Debug 后画出来的血泪地图。

3.1 必须选择 HttpHandler 的 5 种铁律场景

场景一：你需要完全接管 HTTP 响应的生成。
这是 Handler 的“宪法权利”。例如，一个动态生成二维码的服务：用户访问 /qrcode.ashx?text=HelloWorld&size=300 ，Handler 必须读取 QueryString，调用 QRCode 库生成图片字节流，设置 Response.ContentType = "image/png" ，然后 Response.BinaryWrite(bytes) 。Module 做不到这一点，因为它没有权力终结请求。你可能会想：“那我在 EndRequest 里写呢？” 不行。 EndRequest 触发时，Handler 已经执行完毕，Response 的 Header 和 Body 很可能已经被写入缓冲区，此时再 BinaryWrite 会导致 HttpException: Cannot redirect after HTTP headers have been sent 。我踩过这个坑，在一个报表导出模块里，试图用 Module 拦截所有 /export/* 请求并生成 Excel，结果在 IE8 下大面积报错，就是因为 IE 对 Header 的写入时机极其敏感。

场景二：你追求极致的性能和最小的开销。
Handler 绕过了整个 Page 生命周期。对于那些不需要 ViewState、不需要 PostBack、不需要服务器控件的简单服务，Handler 是唯一选择。典型案例如：

• 实时股票行情推送（SSE 或长轮询）
• 图片缩略图服务（ /thumb.ashx?src=/img/1.jpg&w=200&h=150 ）
• 静态资源代理（将 /cdn/xxx.js 请求转发到 CDN 域名）
  在这些场景下，一个 Handler 的内存占用通常只有 20-50KB，而一个空的 .aspx 页面启动后至少占用 2MB。在一台 4GB 内存的服务器上，这意味着 Handler 可以轻松支撑 10 万并发连接，而 Page 可能连 5000 都撑不住。

场景三：你需要为非 .aspx 扩展名提供服务。
ASP.NET 默认只处理 .aspx , .asmx , .ashx 等已知扩展名。如果你想让 /api/user/123.json 这样的 URL 也能被你的 .NET 代码处理，就必须在 web.config 中显式注册 Handler 映射：

<system.webServer>
  <handlers>
    <add name="JsonApiHandler" path="*.json" verb="*" type="MyApp.JsonApiHandler" resourceType="Unspecified" />
  </handlers>
</system.webServer>

Module 无法做到这一点，因为它不参与“URL 到处理器”的路由决策，它只在路由完成后才被通知。

场景四：你需要一个“无状态”的、可被任意复用的计算服务。
比如一个通用的 Base64 编解码服务、一个 JSON Schema 校验服务。这类服务的输入输出完全由 HTTP 方法和 Body 决定，与 Session、Cookie、ViewState 等完全无关。将其封装为 IsReusable=true 的 Handler，可以极大提升吞吐量。我曾为一个物联网平台写过一个 MQTT 协议网关的 HTTP 封装 Handler，它每秒能处理 12000 个设备心跳包，而如果用 Page 实现，峰值只能到 1800。

场景五：你需要精确控制请求的“生死”。
Handler 的 ProcessRequest 方法里，你可以随时调用 context.Response.End() 或 context.ApplicationInstance.CompleteRequest() 来立即终止请求。这对于实现短路逻辑（Short-circuiting）至关重要。例如，在一个防刷接口里，Handler 可以先检查 Redis 中的 IP 访问频次，如果超限，直接 Response.StatusCode = 429; Response.End(); ，后面的任何逻辑（包括 Page 的 Page_Load ）都不会执行。Module 虽然也能在 BeginRequest 里 Redirect ，但 Redirect 本身是一个 302 响应，会产生额外的网络往返，而 Handler 的 End() 是真正的零延迟终止。

3.2 必须选择 HttpModule 的 5 种铁律场景

场景一：你需要在多个、不同类型的 Handler 之间共享逻辑。
这是 Module 存在的唯一理由。想象一下：你的系统里有 50 个 .aspx 页面、20 个 .ashx Handler、5 个 .asmx WebService。你想为所有这些请求统一添加一个 X-Request-ID Header 用于全链路追踪。如果用 Handler 实现，你得在 75 个地方复制粘贴同一段代码。而用一个 Module，在 BeginRequest 里生成 ID 并写入 Response.Headers ，在 EndRequest 里记录日志，一次编写，全局生效。这就是“横切关注点”（Cross-Cutting Concern）的经典定义。

场景二：你需要在 Handler 执行前或后，对 HttpContext 进行深度改造。
Module 的强大之处在于它能“润物细无声”地改变请求环境。例如：

• 多租户支持 ：在 BeginRequest 里，根据 Host Header 解析出租户 ID，并将一个 ITenantContext 对象注入 HttpContext.Items ，供后续所有 Handler 使用。
• 请求体预处理 ：在 BeginRequest 里，如果 Content-Type 是 application/json ，则读取原始 Request Stream，反序列化为一个 JObject ，再存入 Items ，这样 Handler 就不用自己去解析了。
• 响应体压缩 ：在 PostRequestHandlerExecute 里，检查 Response.Filter ，如果未设置 GZip，则用 GZipStream 包装它。
  这些操作，Handler 无法做到，因为它只能“用”环境，不能“造”环境。

场景三：你需要实现基于声明的安全模型（Declarative Security）。
ASP.NET 的 [Authorize] 特性、 web.config 中的 <location> 节点，其底层都是由 UrlAuthorizationModule 和 FileAuthorizationModule 这两个核心 Module 实现的。它们在 AuthorizeRequest 事件中，根据当前用户身份和请求 URL，查询配置文件或数据库，决定是否允许通行。你无法在一个 Handler 里模拟这个过程，因为 Handler 的执行时机太晚，安全检查必须在业务逻辑执行前完成。

场景四：你需要实现精细的、事件驱动的缓存策略。
ASP.NET 的输出缓存（Output Cache）本身就是由 OutputCacheModule 实现的。它在 ResolveRequestCache 事件中检查缓存键，若命中则直接 Response.Write() 并 CompleteRequest() ；在 UpdateRequestCache 事件中，将 Handler 生成的响应内容写入缓存。这种“前置拦截 + 后置写入”的双事件模式，是 Module 的专利。Handler 只能被动地被缓存，无法主动参与缓存决策。

场景五：你需要与 IIS 的原生模块（Native Modules）进行深度集成。
在 IIS 7+ 的集成模式下，托管模块（Managed Module）和本机模块（Native Module）共享同一个请求管道。 WindowsAuthenticationModule 就是托管 Module，但它必须与 IIS 的 iiswam.dll （Windows Authentication Native Module）协同工作，才能完成 NTLM/Kerberos 认证。这种跨托管/本机边界的协作，只有 Module 这种“管道内嵌”机制才能实现。Handler 是管道之外的“黑盒”，它与 IIS 的集成只能停留在 HTTP 协议层面。

4. 陷阱与避坑指南：那些文档里不会写的“死亡细节”

理论再完美，也架不住现实的毒打。下面这些，是我从线上事故、Code Review 红线、以及 Stack Overflow 上数万条“Why does my HttpModule not work?” 问题中，提炼出的、最致命、最高频的五个“死亡细节”。它们往往不会导致编译错误，但会让你的程序在特定条件下悄无声息地崩溃。

4.1 死亡细节一：IIS 7+ 集成模式下的“幽灵失效”

这是 .NET Framework 3.5 SP1 之后最大的兼容性雷区。在 IIS 7 之前，ASP.NET 管道是独立于 IIS 的， web.config 里的 <httpModules> 和 <httpHandlers> 是唯一权威。但在 IIS 7+ 的“集成模式”（Integrated Mode）下，IIS 和 ASP.NET 共享同一个管道，许多原本由托管 Module 完成的工作（如身份验证、静态文件处理），现在由 IIS 的本机模块接管了。结果就是：你精心编写的 CustomAuthModule ，在集成模式下， AuthenticateRequest 事件可能永远不会被触发！因为 IIS 的 WindowsAuthenticationModule 已经在更早的阶段完成了认证，并设置了 HttpContext.User 。解决方案不是禁用集成模式（那是倒退），而是 必须将 Module 注册到 <system.webServer><modules> 节点下，并明确指定 preCondition ：

<system.webServer>
  <modules>
    <!-- 这个 Module 只在托管管道中运行 -->
    <add name="MyLoggingModule" type="MyApp.LoggingModule" preCondition="managedHandler" />
    <!-- 这个 Module 在所有请求（包括 .jpg, .css）中都运行 -->
    <add name="MyHeaderModule" type="MyApp.HeaderModule" preCondition="" />
  </modules>
</system.webServer>

preCondition="managedHandler" 表示只对被 ASP.NET 处理的请求（即 URL 匹配了 <handlers> 规则的请求）生效； preCondition="" （空字符串）表示对所有请求都生效。不加 preCondition ，你的 Module 在集成模式下大概率是“幽灵”——注册了，但不工作。

4.2 死亡细节二： HttpContext.Current 的“线程幻觉”

几乎所有初学者都会犯这个错误：在 Module 的事件处理方法里，把 HttpContext.Current 存成一个类字段，然后在另一个线程（比如 Task.Run ）里去访问它。这是绝对禁止的！ HttpContext.Current 是一个 ThreadStatic 字段，它只在创建它的那个请求线程里有效。一旦你把它传给 Task.Run ，新线程里 Current 就是 null 。更隐蔽的陷阱是：在 Async 方法里， await 之后的代码可能在另一个线程上执行，此时 HttpContext.Current 也可能丢失。正确姿势是： 在 await 之前，把所有需要的数据（如 User.Identity.Name , Request.Url.AbsolutePath ）提取出来，作为局部变量传入异步方法。 我曾在一个邮件发送 Module 里， await smtpClient.SendMailAsync(...) 之后还想写日志到 HttpContext.Items ，结果日志全丢了，因为 Items 在新线程里是空的。

4.3 死亡细节三：Handler 的 IsReusable 与静态字段的“甜蜜陷阱”

IsReusable=true 看起来很美，能节省内存。但它的前提是 Handler 必须是“纯函数式”的。我见过最经典的错误，是在 Handler 里声明了一个 private static Dictionary<string, string> _cache = new Dictionary<string, string>(); ，然后在 ProcessRequest 里做缓存读写。问题在于， static 字段是进程级的，被所有 Handler 实例（无论是否可复用）共享。在高并发下， Dictionary 的 Add 操作不是线程安全的，会导致 ArgumentException: An item with the same key has already been added. 。解决方案只有两个：要么彻底放弃 static ，用 ConcurrentDictionary ；要么，更推荐的做法，是放弃 IsReusable=true ，老老实实让 ASP.NET 每次创建新实例。现代服务器内存充足，这点开销远小于并发 Bug 带来的损失。

4.4 死亡细节四：Module 的 Dispose 方法里的“自杀式清理”

IHttpModule 接口有一个 Dispose() 方法，文档说“用于释放非托管资源”。很多开发者会在这里写 connection.Close() , fileStream.Dispose() 。这是危险的！ Dispose() 方法的调用时机是由 IIS 控制的，它可能在应用池回收、甚至服务器关机时才被调用。此时，你试图关闭的数据库连接，其底层 Socket 可能早已断开， Close() 调用会抛出异常，而这个异常会被默默吞掉，导致资源泄漏。 Module 的 Dispose() 应该是空的，或者只做最轻量的、绝对不会失败的日志记录。 真正的资源清理，应该在事件处理方法里，用 using 语句块来保证。例如，在 EndRequest 里：

public void OnEndRequest(object sender, EventArgs e)
{
    var context = HttpContext.Current;
    // 记录日志
    using (var logWriter = new StreamWriter(@"C:\logs\access.log", true))
    {
        logWriter.WriteLine($"{DateTime.Now} - {context.Request.Url} - {context.Response.StatusCode}");
    }
}

4.5 死亡细节五：Handler 的 ProcessRequest 与 async/await 的“异步黑洞”

在 .NET Framework 4.5 之前， IHttpHandler 接口没有 ProcessRequestAsync 方法。很多开发者为了在 Handler 里用 async ，会写出这样的代码：

public void ProcessRequest(HttpContext context)
{
    // 错误！这会导致请求线程被阻塞
    var result = SomeAsyncMethod().Result;
    context.Response.Write(result);
}

Result 会阻塞当前线程，严重拖慢吞吐量。而如果写成：

public void ProcessRequest(HttpContext context)
{
    // 更错误！这会导致上下文丢失，Response 可能为空
    SomeAsyncMethod().ContinueWith(t => context.Response.Write(t.Result));
}

ContinueWith 的回调可能在另一个线程上执行， context.Response 访问会失败。 在 .NET Framework 中，Handler 的 ProcessRequest 必须是同步的。 如果你必须做异步 IO（如调用 Web API），唯一安全的方式是使用 Task.Wait() 或 Task.GetAwaiter().GetResult() ，但这依然有阻塞风险。最佳实践是： 将异步逻辑下沉到业务层，Handler 只做同步的胶水代码。 或者，升级到 .NET 4.5+，使用 IHttpAsyncHandler 接口，它有 BeginProcessRequest 和 EndProcessRequest 方法，这才是为异步设计的正统方式。

5. 迁移与演进：当 .NET Core / .NET 5+ 来敲门

技术不会停滞，ASP.NET 也不会。当你手头的 Legacy 系统需要迁移到 .NET Core 或 .NET 5+ 时，“HttpHandler vs HttpModule” 这个问题并没有消失，而是被更优雅、更强大的新范式所取代。理解这种演进，不是为了怀旧，而是为了看清未来架构的脉络。

5.1 .NET Core 中的“精神继承者”：Middleware 与 Endpoint Routing

在 .NET Core 的中间件（Middleware）模型中，HttpModule 的角色被完美继承。一个 Middleware 就是一个函数，它接收 HttpContext ，可以执行任意逻辑，然后决定是调用 next(context) （相当于让请求继续向下流转），还是直接 context.Response.WriteAsync() （相当于终结请求）。这与 Module 订阅事件、Handler 终结请求的二分法，本质上是同一种思想的进化。例如，一个日志 Middleware：

public class LoggingMiddleware
{
    private readonly RequestDelegate _next;
    public LoggingMiddleware(RequestDelegate next) => _next = next;

    public async Task InvokeAsync(HttpContext context)
    {
        // 相当于 Module 的 BeginRequest
        var startTime = DateTime.UtcNow;
        await _next(context); // 调用下一个中间件，相当于继续管道
        // 相当于 Module 的 EndRequest
        var elapsed = DateTime.UtcNow - startTime;
        Console.WriteLine($"Request to {context.Request.Path} took {elapsed.TotalMilliseconds}ms");
    }
}

而 HttpHandler 的角色，则被 Endpoint Routing 和 Minimal APIs 所取代。一个 Minimal API 的终结点：

app.MapGet("/api/data", () => 
{
    // 这里就是 ProcessRequest 的逻辑
    return Results.Ok(new { Data = "Hello World" });
});

它不再需要实现一个接口，而是直接是一个委托（Delegate），职责单一、启动飞快，完美继承了 Handler “轻量、终结、专用”的精髓。 MapGet , MapPost , MapControllers 这些方法，就是新时代的 <httpHandlers> 映射。

5.2 迁移策略：不是重写，而是“翻译”

将旧的 HttpModule/Handler 迁移到 .NET Core，不是推倒重来，而是“翻译”。我的经验是遵循三步走：

1. Module → Middleware ：将 Module 的每个事件处理方法，翻译成 Middleware 中对应位置的代码。 AuthenticateRequest → 在 UseAuthentication() 之前； AuthorizeRequest → 在 UseAuthorization() 之后； EndRequest → 在 Use(async (ctx, next) => { await next(); /* 日志 */ }) 。
2. Handler → Minimal API 或 Controller Action ： .ashx Handler 直接翻译成 MapGet/MapPost ； .aspx 页面的业务逻辑，翻译成 Controller 的 Action 方法。注意， .aspx 的 UI 层面，需要迁移到 Razor Pages 或 Blazor。
3. 配置 → Program.cs ： web.config 中的 <httpModules> 和 <httpHandlers> ，全部消失，取而代之的是 Program.cs 中的 app.Use...() 和 app.Map...() 调用。顺序变得前所未有的重要，因为 Middleware 的执行顺序就是注册顺序。

5.3 一个不能回避的真相：为什么新框架要抛弃旧名字？

微软没有保留 HttpModule 和 HttpHandler 这两个名字，是有深刻原因的。在旧框架中，它们是“魔法”——你注册一个类型，IIS 就会自动创建实例、调用方法，但你很难知道它何时创建、何时销毁、如何复用。这种黑盒带来了巨大的调试难度和学习成本。而在 .NET Core 中，Middleware 是一个显式的、可调试的、可单元测试的委托链；Endpoint 是一个显式的、可路由的、可过滤的终结点。 名字的消失，标志着 ASP.NET 从“配置驱动”走向了“代码驱动”，从“魔法”走向了“透明”。 这不是功能的削弱，而是力量的解放。你不再需要记住 20 多个事件名称，只需要理解 HttpContext 的生命周期，和 next 委托的含义。这正是我过去十年最深刻的体会：技术的终极目标，从来不是增加复杂性，而是降低认知负荷，让开发者能把精力聚焦在真正的业务价值上。

我个人在实际迁移一个大型政府审批系统时发现，旧的 12 个 HttpModule 和 8 个 HttpHandler，翻译成 .NET 6 的代码后，不仅逻辑更清晰、性能提升 40%，最关键的是，新入职的 junior 开发者，能在两天内完全理解整个请求流程，而以前，他们需要花两周时间去啃那本厚厚的《ASP.NET Internals》。这，或许就是技术演进最朴素的价值。