周恰恰我招人时经常问一个问题：同样能处理请求，什么时候用HttpModule，什么时候用HttpHandler？这个问题看着基础，但真能回答清楚的人不多。更常见的情况是，能背出“Module是管道事件，Handler是处理程序”这种标准定义，可一落到真实项目里就开始凭感觉选：日志放Module，鉴权放Module，接口输出也用Module，直到遇见Session报错、重定向死循环、静态资源性能下降才回头补课。
这篇文章不准备把MSDN抄一遍，而是直接回答最关键的那个问题：在真实项目里，怎么判断一个需求该用HttpModule还是HttpHandler？我会从管道模型讲起，通过几个典型场景，把我踩过的坑和最后的判断方法都交代清楚，适合刚开始接触ASP.NET管道模型的开发，也适合带新人的老手直接拿去当培训材料。
1. 请求管道里的两个“乘客”：Module和Handler各自的座位
1.1 一个请求进入IIS后到底发生了什么
要回答选型问题，先得知道这两个组件在ASP.NET请求生命周期里各自处于什么位置。
一次典型的ASP.NET请求是这样的：IIS收到HTTP请求后，如果是托管资源（比如.aspx、.ashx，或者在集成模式下配置好的路径），会把它交给ASP.NET运行时的HttpApplication管道。这个管道本身是一个事件链：BeginRequest → AuthenticateRequest → AuthorizeRequest → ResolveRequestCache → AcquireRequestState → PreRequestHandlerExecute → 执行Handler → PostRequestHandlerExecute → ReleaseRequestState → UpdateRequestCache → EndRequest。部分事件之后还有对应的PostXxxRequest事件，这里不逐一展开，但你要知道这个顺序是固定的。
HttpModule就挂在管道的事件链上，通过订阅其中任何一个事件，实现对“每个请求必经阶段”的干预。它更像管道里的过滤器，可以在请求前、后甚至异常时插入自己的逻辑。HttpHandler则不在这些事件中间，它处于管道的终点：当管道走到PreRequestHandlerExecute，ASP.NET会找到当前请求对应的Handler，调用它的ProcessRequest方法，把整个请求的处理权交给它。换句话说，一个请求真正去执行“业务动作”的那一步，就是Handler在跑。
1.2 Module在管道上做什么，Handler在管道末端做什么
因为位置不同，两者的职责天然发生了分流。Module适合做横切关注点：与具体页面逻辑无关、但对所有请求都要做的通用逻辑。比如登录校验、访问日志、异常捕获、请求头注入、URL重写。这些逻辑如果散落在每个页面代码里就是灾难，放在Module里，则在管道事件触发时统一执行。
Handler适合做请求的“终点处理”：当需要针对特定URL或扩展名生成响应内容时，比如动态输出JSON、XML、图片、文件下载，甚至一个自定义的RSS源。它做的事情通常是读取请求参数，写一段响应内容，然后结束。Handler不关心别人的请求长什么样，它只负责“被命中时，把内容给我吐出来”。
这里有个容易混淆的点：Module里也可以调用Response.Write，Handler里也可以做权限校验，功能上有重叠，但这种做法会导致职责混乱，后期维护成本很高。判断标准不是“能不能”，而是“合不合适”。功能能不能做，和能力边界无关；职责放到哪里，才是选型真正要回答的问题。
1.3 用快递分拣来理解两者关系
如果觉得概念还是抽象，可以用一个快递分拣中心来比喻。请求是快件，IIS是收货口，HttpModule是分拣线上的一道道传送带：有的传送带负责喷码，有的负责称重，有的负责检查面单——所有快件都会经过这些传送带。HttpHandler则是把快件送进对应的货车：这一件走A区线路，那一件走B区线路，到了目的地才会被真正打开，装车动作就是ProcessRequest。
注意，分拣线上会有很多道传送带，但一辆货车只会装对应线路的快件。也就是说，一个请求会依次经过多个HttpModule，但最终只会交给一个HttpHandler。这个“一个请求只有一个Handler，但可以有很多Module”的差别，是后续所有选型判断的起点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 核心分工与差异对照：一个筛选请求，一个处理请求
2.1 生命周期和执行时机的差异
Module的生命周期挂在HttpApplication上。它没有“处理完成”的说法，就是管道里的事件订阅者。事件按固定顺序触发，每个Module都可以在不同的时间点插入。IIS7集成模式下，Module还可以订阅事件链之外的事件，比如LogRequest、PostLogRequest，这让它能触及的请求阶段变得更细。
Handler的生命周期非常简单：命中URL → 进程内实例化（或复用）→ 调用ProcessRequest → 结束。它在整个请求过程中的参与时间很短，只有“处理”那一小段。正因为它生命周期短，Handler通常更适合做成无状态的对象，处理完当前请求不保留任何中间数据。如果Handler里放了大量实例字段，也就是有状态处理，就必须警惕实例复用带来的并发污染。
2.2 一个请求对应一个Handler，但可以有多个Module
这是最常见的考点，也是实际选型的重要依据。多个Module可以注册到同一个管道事件上，依次执行，互相之间不排斥。比如一个站点可以同时挂日志Module和权限Module，它们彼此独立，先后执行，各自完成自己的任务。
H