常见原因是模块注册位置错误或IIS未启用模块；需确认实现IHttpModule、部署到bin目录、type含完整类名和程序集名、preCondition匹配请求类型，并检查IIS模块功能是否启用。
为什么 <system.webServer><modules> 配置不生效
常见现象是加了自定义模块（比如 MyAuthModule）但完全没被调用，或 IIS 报错 HTTP Error 500.19 - Internal Server Error，提示配置节被锁定。根本原因通常是模块注册位置不对，或未在 IIS 级别启用对应模块。
实操建议：
- 确认模块类型是否实现了
IHttpModule接口，且程序集已部署到bin/目录（非 GAC） -
<modules>下添加模块时，必须用type属性指定完整类名+程序集名，例如：type="MyApp.MyAuthModule, MyApp" - 若模块依赖
managedHandler处理管道，需确保<add name="..." type="..." preCondition="managedHandler" />中的preCondition匹配当前请求（如静态文件默认不走 managedHandler） - 检查 IIS 中“模块”功能是否启用：打开 IIS 管理器 → 选择站点 → 双击“模块”，确认右侧“配置编辑器”中“section”为
system.webServer/modules，且“From”显示为ApplicationHost.config或web.config（而非被父级锁定）
如何让自定义模块在所有请求（包括 .js/.css）中运行
默认情况下，IIS 会跳过静态文件的托管管道，所以 preCondition="managedHandler" 会让模块对 .js、.css 等请求失效。这不是 bug，是性能优化设计。
实操建议：
- 去掉
preCondition属性，或设为preCondition=""（空字符串），模块就会参与所有请求生命周期 - 但要注意：此时模块会在
BeginRequest就介入，而静态文件可能尚未被 IIS 的静态文件模块处理，HttpContext.Current.Request.Path是可用的，但HttpContext.Current.Handler为null - 若需操作响应体（如注入脚本），改用
EndRequest事件更安全；若只做日志或鉴权，AuthenticateRequest更合适 - 务必在模块中判断
request.Path.EndsWith(".js")等条件再执行逻辑，避免对静态资源做无谓处理
runAllManagedModulesForAllRequests="true" 到底要不要开
这个设置会让所有请求（哪怕 .html、.jpg）都进入 ASP.NET 管道，看似“一劳永逸”，实际代价不小：CPU 升高、缓存失效、静态文件失去 IIS 原生压缩和 ETag 支持。
实操建议：
- 绝大多数场景下不要开 —— 它是“懒人开关”，掩盖了模块注册逻辑问题
- 仅当业务强依赖统一入口（如全站 A/B 测试路由、统一灰度 Header 注入），且已评估性能影响后才考虑启用
- 如果开了，必须配合
<remove name="StaticFile" />或调整preCondition，否则 IIS 静态文件模块和你的模块可能冲突 - 替代方案更推荐：用
<add name="..." preCondition="integratedMode,runtimeVersionv4.0" />显式控制作用域
模块加载顺序和 add/remove 的坑
IIS 模块按 <modules> 中声明顺序执行 Init()，但事件触发顺序由 IIS 内部管道决定（如 BeginRequest 总在 AuthenticateRequest 之前）。乱序 <remove> 可能导致后续模块找不到依赖。
实操建议：
- 要替换系统模块（如用自定义认证代替
FormsAuthenticationModule），先<remove name="FormsAuthentication" />，再<add name="MyAuth" type="..." /> - 不要在子目录
web.config中<remove>父级已删掉的模块，IIS 会报错Failed to initialize module because it does not implement IHttpModule - 调试加载顺序：在模块
Init()中写日志，或用System.Web.HttpModuleCollection.AllKeys在运行时检查当前已注册模块列表 - 注意
name必须严格匹配（大小写敏感），<remove name="UrlAuthorization" />和<remove name="urlAuthorization" />效果不同
模块配置最麻烦的不是语法，而是它隐式依赖 IIS 工作模式、ASP.NET 运行时版本、甚至应用程序池的托管管道模式。一个 preCondition 写错，或者少一个逗号，就可能让整个请求链静默失败——没有错误，只有结果不对。
