ASP.NET页面要在服务器上跑起来，运行光把.aspx文件丢进目录里是环境没用的。IIS得先认出这是运行个动态请求，然后交给ASP.NET运行时去编译、环境执行，运行再把生成的环境HTML吐回浏览器。整套流程里缺一个环节，运行页面就是环境404或者500。

我见过太多人第一次部署aspx站点时踩的运行坑：装了IIS，把文件拷进wwwroot，环境浏览器一打开——直接下载了一个.aspx文件。运行原因很简单，环境IIS没装ASP.NET模块，运行它把这玩意儿当静态文件处理了。环境Windows上解决这个问题的运行办法是在"启用或关闭Windows功能"里勾上Internet Information Services → World Wide Web Services → Application Development Features → ASP.NET 4.x。勾完之后IIS会注册一个ISAPI过滤器，把.aspx、.ashx、.asmx这些扩展名映射到aspnet_isapi.dll上，请求才算真正进入.NET的世界。

IIS和ASP.NET之间的关系，可以理解为前台和后台。IIS负责监听端口、管理应用程序池、处理静态资源、做反向代理。ASP.NET运行时负责页面生命周期、控件树构建、ViewState处理、Session管理这些脏活累活。两者之间通过ISAPI扩展通信。应用程序池是关键——每个池是一个独立的w3wp.exe进程，里面加载着CLR。池挂了，站点就挂了。池回收了，Session如果存在进程内，全部丢失。

CLR版本要匹配。IIS应用程序池有"托管管道模式"和".NET CLR版本"两个设置。经典模式（Classic）走的是ISAPI扩展的老路子，集成模式（Integrated）让ASP.NET直接挂进IIS的请求管道。集成模式下URL重写、身份验证这些模块可以统一配置，经典模式下ASP.NET的HttpModule和IIS的NativeModule各管各的，经常打架。新项目没理由用经典模式，但老系统迁移过来的时候，这个设置不改，页面直接报500.23。

Web.config是另一个高频雷区。连接字符串、身份验证模式、customErrors、httpHandlers、httpModules——这些东西配错了，IIS给的报错信息往往含糊其辞。我印象最深的一次是customErrors设成RemoteOnly，本地调试一切正常，远程访问只看到"运行时错误"五个字，查了两小时才发现是web.config里一个拼错的section name。后来养成了习惯，部署前先把customErrors关掉，看到黄页面的详细堆栈再说。

还有32位和64位的坑。老版本的Access数据库驱动、某些COM组件只有32位版本，应用程序池如果跑在64位模式下，一调用就崩。解决办法是把应用程序池的"启用32位应用程序"设为True。代价是内存上限降到2GB左右，大站点扛不住。所以能升级组件就升级，别硬撑。

权限问题也绕不开。IIS应用程序池默认用一个虚拟账户（IIS AppPool\你的池名称）运行。这个账户对站点目录得有读取权限，对App_Data这类需要写入的目录得有修改权限。很多人部署完发现图片上传失败或者SQLite写不进去，查半天代码，其实是NTFS权限没给够。用Process Monitor抓一下Access Denied，一目了然。

说到底，aspx运行环境不是装个IIS就完事。IIS版本、ASP.NET版本、CLR版本、管道模式、应用程序池身份、NTFS权限、web.config配置——这些环节像链条一样扣在一起。哪一节断了，页面就出不来。排查问题的顺序应该是：先看IIS有没有收到请求（日志），再看ASP.NET有没有开始处理（事件查看器），最后看代码本身有没有抛异常（自定义错误页关掉看堆栈）。顺着这条线走，大部分环境问题都能定位到具体那一环。

(责任编辑：知识)