ASP.NET网站IIS部署核心三关：扩展映射、通配符路由与权限配置

1. 项目概述：为什么部署ASP.NET网站不是“复制粘贴”就能跑起来？

在IIS6和IIS7.5上部署一个ASP.NET网站，对很多刚从Visual Studio开发环境走出来的程序员来说，常有一种“明明代码没问题，怎么一放IIS就报错”的挫败感。我带过十几支小团队，几乎每支队伍的新人都会卡在同一个地方：把本地调试好好的网站丢进IIS，浏览器里弹出“HTTP Error 404.3 - Not Found”或者“HTTP Error 500.22 - Internal Server Error”，然后对着错误日志发呆半小时。这不是你技术不行，而是ASP.NET的运行机制和IIS的请求处理模型之间存在几道必须手动打通的“关卡”。这些关卡，在VS自带的开发服务器（Cassini）里是自动绕开的，但IIS不会替你做任何假设——它只认配置。

核心关键词其实就三个：扩展名映射、通配符处理、权限控制。它们分别对应着IIS如何把一个URL请求“交到”ASP.NET手里，以及ASP.NET拿到请求后有没有权限去读写文件或数据库。比如你看到/mvc/Customers这个地址能正常打开，但点一下/AjaxStyle/SetStyle.cspx就404，问题根本不在你的C#代码，而在于IIS压根没把.cspx这个后缀的请求转发给ASP.NET引擎；再比如你填好了SQL Server连接字符串，却提示“登录失败”，十有八九不是密码错了，而是SQL Server服务进程（sqlservr.exe）运行所用的Windows账户，没有被授予访问你那个MyNorthwind.mdf文件所在目录的“读取+写入”权限。这些细节，web.config里一句也写不出来，必须靠你在IIS管理器里亲手点出来。

这篇文章要讲的，就是如何像修车师傅一样，拿着示波器（Fiddler/Firebug）、扳手（IIS管理器）和螺丝刀（Windows安全策略），一步步定位、拆解、修复这三道关卡。我不讲抽象概念，只说你鼠标该点哪里、对话框里哪个复选框绝对不能勾、哪行配置改错一个字符就会让整个网站瘫痪。所有操作都基于真实生产环境验证过：Windows Server 2003 + IIS6 和 Windows 7 + IIS7.5 这两套最典型的组合。你会发现，IIS6像一台需要手动调校的老式柴油机，每个喷油嘴（扩展名映射）都得你亲自拧紧；而IIS7.5则像一辆预设好ECU的现代轿车，你只要把“发动机参数表”（web.config里的<system.webServer>节）填对，它自己就能完成大部分匹配。但无论新旧，底层逻辑没变：IIS是门卫，ASP.NET是管家，web.config是管家的指令手册，而Windows权限是门卫的上岗证。缺了哪一环，门都进不去。

2. 核心设计思路：IIS6与IIS7.5的本质差异与选型逻辑

2.1 为什么必须区分IIS6和IIS7.5？——管线模型的根本性重构

很多人以为IIS7.5只是IIS6的“界面升级版”，点点鼠标更方便而已。这是个致命误解。真正决定部署难易度的，是二者背后完全不同的请求处理管线（Request Processing Pipeline）。这个差异直接决定了你配置的工作量、出错概率，甚至影响你后续的架构选型。

IIS6采用的是经典的两阶段分离模型。第一阶段由IIS内核处理：它收到一个HTTP请求（比如GET /Default.aspx），先检查URL后缀（.aspx），然后查自己维护的“扩展名-可执行文件”映射表。如果找到，就把这个请求转给对应的ISAPI筛选器（aspnet_isapi.dll）；如果没找到（比如.cspx），直接返回404，连ASP.NET的边都摸不到。第二阶段才是ASP.NET自己的事：aspnet_isapi.dll把请求交给ASP.NET运行时，后者再根据web.config里的<httpHandlers>节，匹配path="*.cspx"这样的规则，最终路由到你的AjaxHandlerFactory。你看，这里存在两次独立的匹配：IIS一次，ASP.NET一次。你必须在两个地方都配对，缺一不可。这就是为什么IIS6部署总让人提心吊胆——多一道环节，就多一个出错点。

IIS7.5则彻底重构为统一集成管线（Integrated Pipeline）。它把IIS内核和ASP.NET运行时“焊死”在一起。当请求进来，IIS不再按后缀粗暴分流，而是直接把整个HTTP上下文（包括Headers、Body、QueryString）一股脑儿交给ASP.NET。ASP.NET此时既是“处理器”又是“配置中心”，它能直接读取web.config里的<system.webServer><handlers>配置，并实时生效。你写的<add path="/mvc/*" verb="*" type="MyMVC.MvcPageHandlerFactory..." />，IIS7.5会原样照搬，无需你在IIS管理器里额外添加任何映射。这种设计下，web.config成了唯一的真理来源，部署逻辑瞬间清晰：写好config，建好站点，搞定权限，完事。我实测过，一个标准的MVC2网站，在IIS7.5上从解压到可访问，平均耗时3分17秒；在IIS6上，光是排查/mvc/*通配符映射失败导致的500错误，就可能耗掉你一整个下午。

提示：如果你的项目必须兼容IIS6（比如客户还在用Windows Server 2003），那么你的web.config里<httpHandlers>的path属性必须极度简化，只能用*.ext格式。像path="/mvc/*"或path="*Ajax*/*.cspx"这种正则风格的写法，在IIS6的ISAPI映射里是无效的，强行使用只会让你的网站在本地跑得好好的，一上服务器就集体失联。

2.2 经典模式 vs 集成模式：IIS7.5的兼容性开关

IIS7.5为了照顾海量存量IIS6应用，提供了一个叫“经典模式（Classic Mode）”的兼容开关。开启它，IIS7.5就假装自己是IIS6，走两阶段分离的老路；关闭它（即使用默认的“集成模式”），才发挥统一管线的优势。这个开关藏在应用程序池的高级设置里，位置隐蔽但影响巨大。

我强烈建议：新项目一律使用集成模式，老项目迁移时优先尝试集成模式。原因很实在：经典模式下，你依然要面对IIS6时代的所有坑——扩展名映射、通配符配置、<system.web>和<system.webServer>配置并存且容易冲突。而集成模式下，<system.webServer>是唯一权威，<system.web>里的<httpHandlers>会被忽略（除非你显式启用兼容性）。这意味着你不用再纠结“这个handler该写在哪个section里”，也不用担心IIS6的旧脚本在IIS7.5上因配置重复而报错。我在一个金融客户的迁移项目中做过对比：同样一套ASP.NET Web Forms代码，在经典模式下需要修改7处web.config配置并添加3条IIS映射；切换到集成模式后，只保留<system.webServer>里的handlers，其他全部删掉，重启应用池，一次通过。

注意：切换模式后必须重启应用池，仅重启网站无效。因为应用池的管线模式是在进程启动时加载的，运行中无法热切换。这点和IIS6完全不同，IIS6里改个映射点下“确定”就立刻生效。

2.3 工具链选择：为什么坚持用Fiddler2和Windows任务管理器？

部署过程中，90%的“神秘错误”都源于信息不对称：你看到的是浏览器的404页面，但真正的问题可能发生在IIS拒绝转发、ASP.NET找不到handler、还是SQL Server权限不足？这时候，依赖IIS日志（%SystemDrive%\inetpub\logs\LogFiles）效率太低，日志里全是时间戳和状态码，看不出上下文。我的固定搭档是Fiddler2和Windows任务管理器。

Fiddler2是HTTP协议的“透视镜”。当你点击页面上的/AjaxStyle/SetStyle.cspx链接，Fiddler能清晰显示：

• 第一行是浏览器发出的GET http://localhost:25678/AjaxStyle/SetStyle.cspx请求；
• 第二行是IIS返回的HTTP/1.1 404 Not Found响应；
• 关键是第三行：X-AspNet-Version: 2.0.50727—— 这说明请求压根没进ASP.NET，因为如果进了，响应头里会有X-AspNetMvc-Version之类的标识。这就一锤定音：问题出在IIS到ASP.NET的“桥”断了，下一步直接去IIS管理器查.cspx映射，而不是去翻C#代码。

Windows任务管理器则是权限问题的“定位仪”。当XML写入失败或SQL Server附加数据库报“拒绝访问”，你第一反应不该是瞎猜“是不是NETWORK SERVICE权限不够”，而是打开任务管理器→“详细信息”页→找到w3wp.exe（IIS工作进程）和sqlservr.exe（SQL Server进程）→右键“转到服务”→看它们关联的服务名（如W3SVC、MSSQL$SQLEXPRESS）→再右键服务名“属性”→“登录”选项卡，确认实际运行账户。这个过程比查文档快十倍，而且100%准确。我见过太多人凭记忆去C:\Windows\System32\inetsrv\config\applicationHost.config里找identity，结果发现那只是应用池的默认设置，实际运行账户可能被覆盖为ApplicationPoolIdentity。

3. IIS6深度实操：三步打通请求通道与权限闭环

3.1 扩展名映射：手把手配置.cspx与.ascx的ISAPI接管

在IIS6中，让.cspx这类自定义扩展名生效，本质是告诉IIS：“凡是带.cspx后缀的请求，别自己处理，转给ASP.NET的ISAPI模块去办。”这个过程看似简单，但有三个极易踩中的陷阱，我用一个真实案例说明。

场景还原：你下载了MyMVC DEMO，解压到D:\MyMVC，在IIS6里新建网站，主目录指向D:\MyMVC，绑定端口25678。浏览器访问http://localhost:25678，首页正常；但点击右上角【3】切换皮肤，Fiddler抓包显示GET /AjaxStyle/SetStyle.cspx返回404。打开web.config，确认<httpHandlers>里有<add path="*.cspx" ... />。现在开始配置。

第一步：定位ISAPI路径（关键！）
不要试图手打aspnet_isapi.dll路径。正确姿势是：在IIS管理器中，展开“网站”→右键你的网站→“属性”→“主目录”选项卡→点“配置”按钮。在弹出的“应用程序配置”窗口里，找到已存在的.aspx条目（通常排在最前面），双击它。你会看到一个对话框，其中“可执行文件”栏显示类似C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll的完整路径。立即复制这个路径（Ctrl+C），然后点“取消”退出。为什么不能点“确定”？因为点“确定”会触发IIS验证，而.aspx条目本身是受保护的，修改它可能导致整个网站崩溃。我们只要它的路径值。

第二步：添加.cspx映射（注意复选框！）
回到“应用程序配置”窗口，点“添加”按钮。在新弹出的对话框里：

• “可执行文件”：粘贴刚才复制的路径；
• “扩展名”：输入.cspx（注意开头的点，必须有）；
• “动作”：保持默认的“限制为GET,HEAD,POST,DEBUG”；
• 最关键一步：“确认文件是否存在”：务必取消勾选！
  这个复选框是IIS6最反直觉的设计。勾选它，IIS会在磁盘上查找SetStyle.cspx这个物理文件，找不到就直接404，根本不把请求交给ASP.NET。而我们的.cspx是虚拟路径，对应的是AjaxHandlerFactory的代码逻辑，磁盘上当然没有这个文件。我曾帮一个客户排查，他们勾选了这个框，折腾两天以为是代码bug，最后发现只是UI里一个复选框没取消。

第三步：验证与扩展（.ascx同理）
点“确定”保存，关闭所有对话框。重启网站（右键网站→“停止”，再“启动”）。用Fiddler重新抓包，这次应该能看到200 OK响应，且响应体是你期望的JSON数据。对于.ascx（用户控件）这类IIS6默认禁止的扩展名，配置方法完全相同：复制.aspx的ISAPI路径，添加.ascx映射，同样取消“确认文件是否存在”。切记，.ascx不是用来直接访问的，但某些AJAX框架会把它当资源加载，不配置照样404。

实操心得：IIS6的映射列表是有序的，匹配规则是“从上到下第一个匹配”。所以把最常用的.aspx、.asmx放在前面，自定义的.cspx放在后面。如果顺序乱了，可能出现.cspx请求被上面某个宽泛规则（如*.*）截胡的诡异现象。

3.2 通配符应用程序映射：解决/mvc/*等无扩展名路由的终极方案

当你的网站用了ASP.NET MVC或自定义路由，URL变成/mvc/Customers、/api/products这种没有扩展名的形式时，IIS6的扩展名映射就彻底失效了。因为IIS6的映射表只认后缀，/mvc/*这种路径模式它根本看不懂。这时，你必须启用“通配符应用程序映射（Wildcard Application Mapping）”，这是IIS6为应对现代Web框架而留的后门。

操作流程（比扩展名映射多一步，但更一劳永逸）：

1. 回到网站“属性”→“主目录”→“配置”→“应用程序配置”窗口；
2. 点“插入...”按钮（注意是“插入”，不是“添加”）；
3. 在弹出的对话框里，“可执行文件”粘贴.aspx的ISAPI路径（同上）；
4. “确认文件是否存在”：同样必须取消勾选！（理由同上）；
5. 点“确定”，你会看到新条目出现在映射列表最顶端，类型显示为“通配符”。

为什么必须放在最顶端？
通配符映射是“兜底”规则，它会捕获所有未被前面精确扩展名匹配的请求。如果它排在.aspx下面，那么/Default.aspx这种请求会被上面的.aspx条目吃掉，而/mvc/Customers才会轮到通配符。但如果通配符在最上面，它会先于所有其他规则生效，确保所有请求（包括.aspx）都先经过ASP.NET。这听起来有点暴力，但恰恰是IIS6支持MVC的唯一可靠方式。

副作用与权衡：
启用通配符后，你的网站性能会有微乎其微的下降（每次请求多一次ISAPI调用），但换来的是配置的极简——你不再需要为.cspx、.mvc、.api等一堆自定义后缀单独配置映射。所有路由逻辑都收归web.config的<httpHandlers>管理。我在一个电商后台项目中强制启用了通配符，结果发现/admin/reports/sales.csv这种导出CSV的请求也能被CsvHandler完美处理，而不用额外配.csv映射。不过，这也意味着你必须确保web.config里<httpHandlers>的path规则足够严谨，否则可能误伤静态资源（如/images/logo.png被当成动态请求处理）。解决方案是在<httpHandlers>里把静态资源排除掉，例如：

<add path="*.png" verb="*" type="System.Web.StaticFileHandler" validate="true"/> <add path="*.jpg" verb="*" type="System.Web.StaticFileHandler" validate="true"/> <add path="/mvc/*" verb="*" type="MyMVC.MvcPageHandlerFactory, MyMVC" validate="true"/>

提示：通配符映射一旦启用，.cspx的单独映射就变得多余，可以删除。但保留也无害，只是多了一层冗余匹配。

3.3 目录权限配置：App_Data与SQL Server数据文件的写入授权实战

ASP.NET网站崩溃的第二大原因，不是代码，而是权限。IIS6默认以NETWORK SERVICE账户运行工作进程（w3wp.exe），这个账户在Windows Server 2003上权限极低，连读取C:\Inetpub\wwwroot下的文件都可能被拒，更别说写入App_Data或SQL Server的.mdf文件了。配置权限不是“右键→属性→安全→添加用户→勾选完全控制”这么简单，这里有精确到字节的操作规范。

App_Data目录写入权限（XML数据源场景）：

1. 在Windows资源管理器中，导航到你的网站根目录（如D:\MyMVC），找到App_Data文件夹；
2. 右键App_Data→“属性”→“安全”选项卡；
3. 点“编辑”→“添加”→在“输入对象名称”框里输入NETWORK SERVICE（注意空格，大小写不敏感），点“检查名称”确认，点“确定”；
4. 在下方权限列表中，只勾选“写入”和“修改”，其他全不勾。为什么？因为App_Data里只存XML数据文件，不需要执行权限（“读取和执行”），也不需要更改所有权（“取得所有权”）。过度授权是安全隐患的温床；
5. 点“确定”保存。此时，NETWORK SERVICE对App_Data拥有写入权，但对父目录D:\MyMVC依然只有读取权，符合最小权限原则。

SQL Server数据文件权限（.mdf附加场景）：
SQL Server的权限问题更隐蔽。当你在SSMS里点击“附加”却报“操作系统错误5: 拒绝访问”，问题往往不在数据库引擎，而在Windows文件系统。关键是要找到sqlservr.exe进程的真实运行账户。

1. 打开Windows任务管理器→“详细信息”页→找到sqlservr.exe进程；
2. 右键→“转到服务”→在服务列表中找到对应实例（如MSSQL$SQLEXPRESS）；
3. 右键该服务→“属性”→“登录”选项卡，确认“此账户”字段。在Windows Server 2003 + SQL Server 2005 Express默认安装下，它通常是.\SQLServer2005SQLAgentUser$YourMachineName$SQLEXPRESS或NT AUTHORITY\NETWORK SERVICE；
4. 假设是NETWORK SERVICE，那么你需要给MyNorthwind.mdf所在的整个目录（如D:\MyMVC\db\）赋予NETWORK SERVICE的“读取&执行”、“列出文件夹内容”、“读取”、“写入”权限（四者缺一不可）。特别注意：必须给目录赋权，而不是单给.mdf文件赋权。因为SQL Server附加时会同时访问.mdf和.ldf（日志文件），如果日志文件缺失，它会尝试在同目录下创建新的.ldf，这就需要目录的“写入”权限。

常见误区：有人会给Everyone账户赋权，以为“一劳永逸”。这是严重错误。Everyone包含所有用户，包括潜在的恶意程序。正确的做法永远是“精准打击”——只给NETWORK SERVICE（或你指定的具体服务账户）授予权限，且仅限于必需的目录和必需的权限。

4. IIS7.5零配置部署：集成模式下的web.config驱动范式

4.1 system.webServer配置节：IIS7.5的唯一真理之源

IIS7.5的革命性在于，它把web.config从“ASP.NET的私有配置文件”升级为“IIS与ASP.NET的联合宪章”。在集成模式下，<system.webServer>节成为IIS7.5读取和执行的唯一依据，<system.web>里的<httpHandlers>和<httpModules>被完全忽略。这意味着，你的部署工作量从IIS6的“配置IIS+配置web.config”压缩为“只配web.config”。但前提是，你必须写对<system.webServer>。

以MyMVC DEMO为例，它需要支持三种请求模式：

• *.cspx→AjaxHandlerFactory
• *.aspx→MvcPageHandlerFactory
• /mvc/*→MvcPageHandlerFactory

对应的<system.webServer>配置如下：

<system.webServer> <handlers> <!-- 处理.cspx请求 --> <add name="CspxHandler" path="*.cspx" verb="*" type="MyMVC.AjaxHandlerFactory, MyMVC" resourceType="Unspecified" preCondition="integratedMode" /> <!-- 处理.aspx请求 --> <add name="AspxHandler" path="*.aspx" verb="*" type="MyMVC.MvcPageHandlerFactory, MyMVC" resourceType="Unspecified" preCondition="integratedMode" /> <!-- 处理/mvc/*通配符请求 --> <add name="MvcWildcardHandler" path="/mvc/*" verb="*" type="MyMVC.MvcPageHandlerFactory, MyMVC" resourceType="Unspecified" preCondition="integratedMode" /> </handlers> </system.webServer>

关键参数解析：

• name：必须全局唯一，用于IIS管理器中识别，建议用业务含义命名（如CspxHandler）；
• path：支持通配符*和?，/mvc/*这种路径模式IIS7.5原生支持，无需通配符映射；
• resourceType：设为Unspecified表示不限制资源类型（文件/目录/不存在的路径都匹配），这是支持/mvc/Customers的关键；
• preCondition="integratedMode"：这是安全阀。它确保这条规则只在集成模式下生效，如果应用池意外切换到经典模式，IIS会自动跳过此规则，避免配置冲突导致500错误。

提示：IIS7.5的<handlers>配置会实时反映在IIS管理器的“处理器映射”功能页中。你添加一条<add>，那里就多一行；你删掉一行，那里就少一行。这让你能直观验证配置是否生效，是IIS6时代梦寐以求的功能。

4.2 fileExtensions解锁：让.cs、.ascx等“危险”扩展名合法化

IIS7.5出于安全考虑，对一些扩展名做了硬性封锁，默认禁止访问。.cs（C#源码）、.ascx（用户控件）、.config（配置文件）都在黑名单里。如果你的框架（如FishWebLib DEMO）用了.cs作为AJAX后缀，直接访问会得到“HTTP Error 404.7 - Not Found”，错误详情里明确写着“请求的文件扩展名被禁止”。这不是ASP.NET的问题，是IIS7.5的<security>模块在拦截。

解锁方法是在<system.webServer>里添加<staticContent>配置，显式声明这些扩展名是允许的：

<system.webServer> <staticContent> <!-- 解锁.cs扩展名 --> <mimeMap fileExtension=".cs" mimeType="text/plain" /> <!-- 解锁.ascx扩展名 --> <mimeMap fileExtension=".ascx" mimeType="text/plain" /> </staticContent> </system.webServer>

为什么mimeType="text/plain"？
因为.cs和.ascx本质上不是要被浏览器执行的资源，而是要被ASP.NET后端处理的“数据载体”。设为text/plain，IIS会把它当作纯文本返回，但更重要的是，这个声明告诉IIS：“我知道这个扩展名，允许它通过，别拦着”。如果不设mimeType，IIS会因找不到对应类型而拒绝请求。text/plain是最安全的选择，它不会触发浏览器的下载或执行行为。

注意：<staticContent>配置需要配合<handlers>里的对应handler才能生效。比如你解锁了.cs，但<handlers>里没有path="*.cs"的规则，请求还是会落到IIS的静态文件处理器，返回源码内容（安全风险！）。所以解锁只是第一步，必须紧接着在<handlers>里添加对应的handler，确保请求被正确路由到你的工厂类。

4.3 应用程序池身份：从NETWORK SERVICE到ApplicationPoolIdentity的平滑过渡

IIS7.5引入了一个更安全的应用程序池身份——ApplicationPoolIdentity。它为每个应用池创建一个唯一的、权限受限的虚拟账户（如IIS APPPOOL\MyMVCAppPool），比NETWORK SERVICE粒度更细、隔离性更强。但在迁移老项目时，直接切换可能引发权限问题，因为老代码习惯性地依赖NETWORK SERVICE的既有权限。

平滑过渡三步法：

1. 先验证旧身份：在IIS管理器中，展开“应用程序池”，找到你的应用池（如MyMVCAppPool），右键→“高级设置”，查看“标识”字段。如果是NetworkService，记录下来；
2. 切换新身份并授予权限：将“标识”改为ApplicationPoolIdentity，点“确定”。然后，去App_Data目录和SQL Server数据目录，添加新账户IIS APPPOOL\MyMVCAppPool，并赋予与之前NETWORK SERVICE相同的权限（写入、读取等）；
3. 更新web.config（可选）：如果代码里有硬编码NETWORK SERVICE的地方（如日志路径、临时文件夹），需同步更新为新账户名。但绝大多数情况下，只需授予权限即可。

为什么推荐ApplicationPoolIdentity？

• 安全性：每个应用池有独立账户，A网站的漏洞无法横向渗透到B网站；
• 可审计性：Windows事件日志里能清晰看到是哪个应用池在访问文件；
• 兼容性：它自动继承IIS_IUSRS组的权限，与IIS7.5的默认配置无缝衔接。我在一个政府项目中强制推行此方案，成功规避了因NETWORK SERVICE权限过大导致的多次安全扫描告警。

5. SQL Server配置与端口/域名绑定：让网站走出localhost

5.1 SQL Server Express实例连接：localhost\sqlexpress的深层含义

connectionString="server=localhost\sqlexpress;database=MyNorthwind;integrated security=sspi;"这串连接字符串里，localhost\sqlexpress不是随便写的。localhost指本地机器，\sqlexpress是SQL Server的命名实例（Named Instance）名称。SQL Server允许在同一台机器上安装多个实例，每个实例有独立的端口、服务和配置。SQLEXPRESS是SQL Server 2005/2008 Express版的默认实例名。

连接失败的三大根源：

1. 实例未运行：打开“服务”管理器（services.msc），找到SQL Server (SQLEXPRESS)，确认状态为“正在运行”。如果被禁用，右键→“启动”；
2. TCP/IP协议未启用：SQL Server默认只启用共享内存协议，远程连接（或某些本地连接）需要TCP/IP。打开“SQL Server 配置管理器”→“SQL Server 网络配置”→“SQLEXPRESS的协议”，右键“TCP/IP”→“启用”，然后重启SQL Server服务；
3. 防火墙拦截：SQL Server Express默认监听动态端口（非1433），Windows防火墙可能阻止。解决方案：在“SQL Server 配置管理器”里，为SQLEXPRESS的TCP/IP协议指定一个固定端口（如1433），然后在防火墙“入站规则”里放行该端口。

Integrated Security=SSPI的权限链：
integrated security=sspi表示使用当前Windows用户身份连接。但当前用户是谁？在IIS环境下，是w3wp.exe进程的运行账户（NETWORK SERVICE或ApplicationPoolIdentity）。所以，NETWORK SERVICE不仅需要文件系统权限，还需要SQL Server的登录权限。在SSMS里，展开“安全性”→“登录名”，右键→“新建登录名”，在“登录名”框输入NT AUTHORITY\NETWORK SERVICE，然后在“用户映射”页，勾选你的数据库（MyNorthwind），并赋予db_owner角色。这才是完整的权限闭环。

5.2 80端口与域名绑定：告别丑陋的:25678

使用非标准端口（如25678）部署，虽然技术上可行，但暴露了开发痕迹，且不利于SEO和用户记忆。将网站迁移到80端口，是专业部署的最后一步。IIS提供了两种主流方案：

方案一：IP地址绑定（适合多网卡或云服务器）

1. 在Windows网络设置中，为网卡添加一个新IP（如192.168.0.222）；
2. 在IIS管理器中，右键你的网站→“编辑绑定”→“添加”→类型选http，IP地址选192.168.0.222，端口填80，主机名留空；
3. 确保没有其他网站绑定到*:80（所有IP的80端口），否则会冲突。
   优势：简单直接，不依赖DNS；劣势：需要额外IP资源。

方案二：主机头绑定（推荐，适合绝大多数场景）

1. 在IIS管理器中，右键网站→“编辑绑定”→“添加”→类型http，IP地址选*（所有未分配IP），端口80，主机名填www.mymvc-demo.com；
2. 在本地C:\Windows\System32\drivers\etc\hosts文件末尾添加：127.0.0.1 www.mymvc-demo.com；
3. 浏览器访问http://www.mymvc-demo.com，即可看到网站。
   优势：零成本，完美模拟生产环境；劣势：仅限本机测试，局域网内其他机器需同步修改hosts。

提示：主机头绑定是IIS的“虚拟主机”技术，它让多个网站共享80端口，IIS根据HTTP请求头里的Host字段（如Host: www.mymvc-demo.com）来决定把请求交给哪个网站。这是现代Web部署的标准实践。

6. 常见问题速查与独家避坑指南

6.1 HTTP错误代码速查表：404、500、502背后的真相

6.2 我踩过的五个深坑与血泪教训

坑一：IIS6通配符映射的“幽灵”残留
现象：删除通配符映射后，/mvc/*请求依然能访问，但新添加的.cspx映射却失效。
原因：IIS6的通配符映射一旦启用，会永久缓存到metabase.xml，即使UI里删了，底层配置还在。
解法：停止IIS服务（net stop iisadmin /y），用记事本打开`%SystemRoot%\System32\inetsrv