1. 从零搭建本地开发环境：IIS与SwitchHosts的配合逻辑
很多人第一次接触本地 Web 开发环境搭建时，第一反应是装一堆集成包，比如 XAMPP、phpStudy 之类的一键工具。这类工具确实省事，但用久了你会发现两个问题：一是版本锁定严重，想换个运行环境版本得整个重装；二是跟生产环境的差异太大，本地跑得好好的，一上线就出各种莫名其妙的状况。我自己在早期也踩过这个坑，后来逐渐转向用 Windows 10 自带的 IIS 来搭本地站点，配合 SwitchHosts 做域名映射管理，这套组合用了几年下来，稳定性和可控性都让我很满意。
IIS 全称 Internet Information Services，是 Windows 系统内置的 Web 服务器组件。它的好处在于跟操作系统深度集成，不需要额外安装运行时依赖，性能开销小，而且配置界面是图形化的，对不熟悉命令行的朋友比较友好。SwitchHosts 则是一个专门用来管理 hosts 文件的小工具，它解决的核心痛点是：本地开发经常需要在多个域名之间切换，手动改 hosts 文件效率极低，而且容易忘记改回来导致各种奇怪的网络问题。这两个工具配合起来，就能在本地模拟出一套接近真实线上环境的站点访问体系。
这套方案适合谁呢？如果你是在 Windows 10 上做 Web 开发的后端或全栈工程师，需要频繁在多个项目之间切换，或者需要模拟多域名、多站点的访问场景，那这套组合非常值得花时间掌握。前端开发者如果需要在本地调试跨域请求、Cookie 作用域、HTTPS 跳转等问题，也能从中受益。哪怕你只是想在本地跑一个静态站点或者做个简单的接口测试，IIS 的轻量特性也比装一整套重量级环境要舒服得多。
接下来的内容我会从整体设计思路讲起，然后拆解 IIS 的核心配置细节，再讲 SwitchHosts 的使用方法和两者配合的完整实操流程，最后把我这些年踩过的坑和排查经验整理出来。整个过程中涉及的操作步骤和参数配置，你都可以直接照着做。
2. 整体方案设计与选型考量
2.1 为什么选 IIS 而不是其他本地服务器
本地 Web 服务器的选择其实不少，Node.js 的 http-server、Python 的 SimpleHTTPServer、Nginx 的 Windows 版、Apache 的 Windows 版，都能跑起来。但我在实际项目中反复对比之后，还是倾向于 IIS，原因有几个层面。
第一是系统集成度。IIS 是 Windows 的可选功能组件，开启之后跟系统共享网络栈和安全管理机制，不需要额外配置防火墙规则就能被本机访问。而 Nginx 或 Apache 的 Windows 版本本质上是移植过来的，在某些系统调用上会有兼容性折损，尤其是涉及文件权限和端口绑定时，偶尔会出现一些难以排查的异常。
第二是管理界面的成熟度。IIS 管理器提供了图形化的站点管理、应用程序池配置、绑定设置、日志查看等功能，对于不习惯手写配置文件的人来说，上手门槛低很多。你可以直接在界面上新建站点、指定物理路径、绑定端口和域名，改完即时生效，不需要重启服务。
第三是应用程序池的隔离机制。IIS 允许你为每个站点分配独立的应用程序池，不同站点之间互不影响。一个站点出问题不会拖垮其他站点，这在同时维护多个项目时特别有用。你可以给每个项目单独设置运行环境版本、管道模式、闲置超时等参数，灵活性很高。
当然 IIS 也不是没有缺点。它的配置文件体系相对复杂，applicationHost.config 的层级结构需要花点时间理解。另外 IIS 对某些非微软技术栈的支持需要额外安装模块，比如 URL Rewrite、Application Request Routing 等。但这些都是一次性配置，配好之后基本不用再动。
2.2 SwitchHosts 解决的核心问题
hosts 文件是操作系统用来做域名解析的本地数据库，优先级高于 DNS 查询。你往里面写一条127.0.0.1 example.local，系统就会把对 example.local 的请求直接指向本机，不再走网络 DNS 查询。这个机制在本地开发中非常关键，因为它让你可以用真实的域名来访问本地站点，而不是用localhost:端口号这种形式。
但手动管理 hosts 文件有几个痛点。一是文件位置深，在C:\Windows\System32\drivers\etc\目录下，每次改都要管理员权限。二是切换麻烦，如果你同时维护三四个项目，每个项目对应不同的域名映射，来回注释和取消注释非常繁琐。三是容易遗忘，调试完忘了把测试用的映射删掉，可能导致正常上网时域名解析异常。
SwitchHosts 就是来解决这些问题的。它提供了方案分组管理、一键切换、语法高亮、远程方案同步等功能。你可以把不同项目的 hosts 配置分成不同的方案，需要哪个就启用哪个，不需要就关掉。它还支持在系统托盘快速切换，不用每次都打开主界面。我用下来最直观的感受是，以前改 hosts 要开记事本、找文件、改内容、保存、确认权限，一套流程下来至少一分钟；现在点一下托盘图标切换方案，两秒钟搞定。
2.3 两者配合的典型场景
IIS 负责在本地监听端口、处理请求、返回响应，SwitchHosts 负责把域名解析到本机。两者配合起来，你就能在浏览器里输入http://myproject.local来访问本地站点，跟访问线上环境一模一样。
这种配合在几种场景下特别有价值。一是多项目并行开发，每个项目有自己的域名，互不干扰。二是模拟多站点交互，比如你有一个前端站点和一个后端 API 站点，需要模拟跨域请求，用不同域名就能真实还原跨域场景。三是 Cookie 和 Session 调试，浏览器的 Cookie 是按域名隔离的，用真实域名才能准确测试登录态和会话保持逻辑。四是 HTTPS 本地调试，配合自签名证书，可以在本地模拟 HTTPS 访问，提前发现混合内容等问题。
3. IIS 核心配置细节与实操要点
3.1 启用 IIS 功能组件
Windows 10 默认没有开启 IIS，需要手动启用。操作路径是：控制面板 → 程序和功能 → 启用或关闭 Windows 功能。在弹出的列表里找到“Internet Information Services”，展开后你会看到一堆子项。
这里有个关键点：不要只勾选最顶层的 IIS 复选框就完事。默认勾选的内容只包含最基础的功能，很多实用模块是没有的。根据我的经验，至少需要额外勾选以下几项：
- Web 管理工具下的“IIS 管理控制台”，这是图形化管理界面，必选。
- 万维网服务 → 常见 HTTP 功能下的“默认文档”“目录浏览”“HTTP 错误”“静态内容”，这些是基础中的基础。
- 万维网服务 → 应用程序开发功能下的“ASP.NET”“.NET 扩展性”“ISAPI 扩展”“ISAPI 筛选器”，如果你要跑 .NET 应用或者需要 URL Rewrite 模块，这些必须开。
- 万维网服务 → 安全性下的“请求筛选”“Windows 身份验证”，调试权限问题时很有用。
- 万维网服务 → 性能功能下的“静态内容压缩”“动态内容压缩”，能提升本地访问速度。
勾选完成后点确定，系统会花几分钟安装。安装完毕后，在浏览器输入http://localhost，如果看到 IIS 的默认欢迎页面，说明安装成功。如果没看到，先检查一下“World Wide Web Publishing Service”这个服务有没有启动，可以在服务管理器里手动启动一下。
注意：启用 IIS 之后，系统可能会自动创建一个默认站点，监听 80 端口。如果你本机已经装了其他占用 80 端口的软件（比如某些聊天工具、下载工具），会导致端口冲突。建议先检查端口占用情况，命令是
netstat -ano | findstr :80，找到占用进程后要么关掉它，要么把 IIS 默认站点换个端口。
3.2 新建站点与应用程序池配置
打开 IIS 管理器，左侧展开服务器节点，右键“网站”选择“添加网站”。弹出的对话框里有几个关键字段需要填写。
网站名称：随便起，建议用项目名，方便识别。比如myproject-dev。
物理路径：指向你项目代码的根目录。这里有个细节，路径中最好不要包含中文和空格，虽然 IIS 支持，但某些模块在处理中文路径时会有编码问题，能避免就避免。
绑定：这是核心配置。类型选 http，IP 地址选“全部未分配”或者127.0.0.1，端口填一个不冲突的，比如 8080。主机名填你打算用的本地域名，比如myproject.local。这里填了主机名之后，IIS 就会根据请求的 Host 头来区分不同站点，实现同一端口多站点共存。
应用程序池：默认会创建一个同名的池子。我建议每个站点单独用一个池，不要共用。点击“选择”可以新建一个池，命名规则建议跟站点名对应，比如myproject-dev-pool。
创建完成后，选中站点，在右侧操作栏点击“基本设置”可以修改物理路径，点击“绑定”可以增删绑定。应用程序池的配置在左侧单独节点里，选中对应的池，右键“高级设置”，有几个参数值得关注：
- .NET CLR 版本：如果你的项目不需要 .NET 运行时，选“无托管代码”可以降低开销。
- 托管管道模式：集成模式是默认的，兼容性更好；经典模式用于一些老应用。
- 闲置超时：默认 20 分钟，本地开发可以改成 0，避免频繁回收导致首次请求变慢。
- 最大工作进程数：本地开发保持 1 就行，多进程会增加调试复杂度。
3.3 默认文档与目录浏览设置
站点建好之后，如果访问时出现 403 或者 404，多半是默认文档没配好。选中站点，双击中间的“默认文档”图标，确保列表里有你项目的入口文件，比如index.html、index.php、default.aspx等。IIS 会按列表顺序从上到下查找，找到第一个存在的文件就返回。
如果你需要浏览目录结构（比如做一个文件下载站或者静态资源站），可以双击“目录浏览”图标，在右侧操作栏点击“启用”。但生产环境千万别开这个，会暴露文件结构。本地开发按需开启即可。
还有一个常见需求是 URL 重写。比如你的项目用了前端路由，访问/user/profile这种路径时，服务器上并没有对应的物理文件，需要重写到index.html。这就需要安装 URL Rewrite 模块。下载安装后，在站点上双击“URL 重写”，添加规则，匹配模式填.*，条件里加上{REQUEST_FILENAME} !-f和{REQUEST_FILENAME} !-d，重写目标填/index.html。这样所有不存在的文件和目录请求都会交给入口文件处理。
3.4 权限与防火墙的坑
IIS 运行站点时，是以应用程序池的身份去读取物理路径的文件的。默认情况下，应用程序池使用IIS AppPool\你的池名这个虚拟账户。如果你的项目目录权限设置不当，就会出现 401.3 或者 500.19 错误。
解决办法是给项目目录添加这个虚拟账户的读取权限。右键项目文件夹 → 属性 → 安全 → 编辑 → 添加，输入IIS AppPool\myproject-dev-pool，检查名称后确定，勾选“读取和执行”“列出文件夹内容”“读取”。如果需要写入权限（比如上传文件功能），再勾选“写入”。
防火墙方面，IIS 安装时会自动添加 HTTP 和 HTTPS 的入站规则，本机访问一般不受影响。但如果你想让局域网内其他设备访问你的本地站点，需要确保防火墙允许对应端口的入站连接。可以在“高级安全 Windows Defender 防火墙”里新建入站规则，开放你使用的端口。
实操心得：我遇到过一种情况，站点配置都正确，但就是访问不了，最后发现是某个安全软件拦截了 IIS 的工作进程。如果你排查了半天找不到原因，不妨暂时关闭安全软件试试，确认问题后再把 IIS 相关进程加入白名单。
4. SwitchHosts 使用详解与域名映射管理
4.1 安装与初始配置
SwitchHosts 是一个开源工具，可以直接从其发布页面下载安装包。Windows 版提供的是 exe 安装程序，双击按提示安装即可。安装完成后首次启动，界面很简洁，左侧是方案列表，右侧是内容编辑区。
第一次打开时，它会自动读取系统当前的 hosts 文件内容，作为一个默认方案显示。你可以直接在这个方案上编辑，也可以新建方案。我建议的做法是：保留系统默认方案不动，新建一个专门用于开发的方案组，把不同项目的映射分开管理。
新建方案时，需要填写方案名称和选择方案类型。类型有“本地”和“远程”两种。本地方案就是直接编辑内容，保存在本地；远程方案用于从某个 URL 拉取 hosts 内容，适合团队统一维护映射规则。本地开发用本地方案就够了。
4.2 方案分组与一键切换
SwitchHosts 最实用的功能就是方案切换。你可以为每个项目建一个方案，比如project-a、project-b、project-c，每个方案里写对应的域名映射。需要调试哪个项目，就在左侧勾选哪个方案，取消勾选其他方案。SwitchHosts 会自动把勾选的方案内容合并写入系统 hosts 文件。
这里有个细节要注意：多个方案同时勾选时，如果存在相同的域名映射，后面的方案会覆盖前面的。所以如果两个项目用了同一个域名，同时启用就会冲突。我的做法是给每个项目分配独立的域名后缀，比如project-a.local、project-b.local，从命名上就避免冲突。
SwitchHosts 还支持在系统托盘快速操作。右键托盘图标，会列出所有方案，点击即可切换启用状态，不用打开主界面。这个功能在频繁切换时特别方便。
4.3 hosts 语法与常见映射写法
hosts 文件的语法很简单，每行一条记录，格式是IP地址 域名，中间用空格或制表符分隔。以#开头的行是注释，不会被解析。
几个常用的映射写法：
# 基本映射，把域名指向本机 127.0.0.1 myproject.local # 同时映射多个域名到同一IP 127.0.0.1 myproject.local api.myproject.local static.myproject.local # 屏蔽某个域名（指向无效地址） 0.0.0.0 ads.example.com # 注释掉暂时不用的映射 # 127.0.0.1 oldproject.local在 SwitchHosts 里编辑时，它提供了语法高亮，IP 地址、域名、注释会有不同的颜色，看起来很清楚。它还支持行内注释，比如127.0.0.1 myproject.local # 项目A开发环境，方便标注用途。
注意：hosts 文件修改后，系统的 DNS 缓存可能不会立即刷新。Windows 上可以运行
ipconfig /flushdns来强制刷新。SwitchHosts 在切换方案后会自动执行刷新操作，但偶尔也会失效，手动刷一下更保险。
4.4 与 IIS 绑定的对应关系
SwitchHosts 里的域名映射，必须和 IIS 站点绑定里的主机名一致，才能正确访问。举个例子，你在 SwitchHosts 里写了127.0.0.1 myproject.local，那 IIS 站点的绑定里主机名也必须填myproject.local，端口要一致。如果 IIS 绑定的是 8080 端口，那你访问的时候要带上端口号：http://myproject.local:8080。
如果你想让访问时不带端口号，那就把 IIS 绑定端口改成 80。但 80 端口通常被默认站点占用，你需要先把默认站点停掉，或者把默认站点的绑定改成其他端口。我一般会把默认站点直接停掉，避免干扰。
还有一种情况是 HTTPS 访问。IIS 支持绑定 HTTPS，需要先创建自签名证书。在 IIS 管理器左侧选中服务器节点，双击“服务器证书”，右侧点击“创建自签名证书”，起个名字比如myproject-dev-cert。然后在站点绑定里添加 https 类型，端口 443，选择刚才创建的证书，主机名填域名。这样就能用https://myproject.local访问了。浏览器会提示证书不受信任，点击“高级”→“继续访问”即可。本地开发这样处理没问题，但要注意某些浏览器对自签名证书的限制越来越严格，必要时可以把证书导入到系统的受信任根证书颁发机构里。
5. 完整实操流程：从零到访问成功
5.1 环境准备清单
在开始之前，先确认以下条件都满足：
| 项目 | 要求 | 检查方式 |
|---|---|---|
| 操作系统 | Windows 10 专业版或企业版 | 设置 → 系统 → 关于 |
| 管理员权限 | 当前账户有管理员权限 | 能打开 IIS 管理器即可 |
| IIS 组件 | 已启用并正常运行 | 访问 localhost 能看到欢迎页 |
| SwitchHosts | 已安装并可正常启动 | 托盘有图标，能打开主界面 |
| 项目代码 | 已准备好，放在本地目录 | 目录路径无中文和空格 |
| 端口 | 80 或自定义端口未被占用 | netstat 检查 |
5.2 第一步：创建 IIS 站点
打开 IIS 管理器，右键“网站”→“添加网站”。填写如下：
- 网站名称：
demo-site - 物理路径：
D:\workspace\demo-site（替换成你的实际路径） - 绑定：类型 http，IP 地址“全部未分配”，端口 80，主机名
demo.local - 应用程序池：新建
demo-site-pool
点击确定。如果 80 端口被占用，IIS 会提示绑定冲突，这时候要么停掉占用端口的程序，要么把端口改成 8080。
5.3 第二步：配置 SwitchHosts 映射
打开 SwitchHosts，新建方案，命名为demo-site。在编辑区写入：
127.0.0.1 demo.local保存后，在左侧勾选这个方案。SwitchHosts 会提示需要管理员权限来修改 hosts 文件，确认即可。勾选后，方案名称旁边会出现一个绿色圆点，表示已生效。
验证映射是否生效：打开命令提示符，运行ping demo.local，如果返回127.0.0.1，说明映射成功。如果返回的是真实 IP 或者提示找不到主机，检查一下方案是否真的启用了，或者手动刷新 DNS 缓存。
5.4 第三步：放置测试文件并访问
在D:\workspace\demo-site目录下创建一个index.html，内容随便写点：
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Demo Site</title> </head> <body> <h1>IIS + SwitchHosts 配置成功</h1> <p>当前访问域名：demo.local</p> </body> </html>确保 IIS 站点的默认文档列表里有index.html。然后在浏览器访问http://demo.local，如果能看到页面内容，说明整套流程跑通了。
5.5 第四步：多站点并行配置
再建一个站点demo-api，物理路径D:\workspace\demo-api，绑定主机名api.demo.local，端口还是 80。应用程序池新建demo-api-pool。
SwitchHosts 里在同一个方案中追加一行：
127.0.0.1 demo.local api.demo.local保存后无需重新勾选，SwitchHosts 会自动更新 hosts 文件。现在你可以同时访问http://demo.local和http://api.demo.local，两个站点互不干扰。
这种配置在调试前后端分离项目时特别有用。前端站点跑在demo.local，后端 API 跑在api.demo.local，前端代码里直接请求http://api.demo.local/xxx，就能真实模拟跨域场景。你可以在后端配置 CORS 头，测试跨域请求是否正常。
5.6 第五步：HTTPS 本地调试配置
如果项目需要 HTTPS，继续以下步骤。在 IIS 管理器选中服务器节点，双击“服务器证书”，右侧“创建自签名证书”，名称填demo-local-cert。
然后选中demo-site，右键“编辑绑定”，添加一条 https 绑定，端口 443，主机名demo.local，SSL 证书选刚才创建的。确定后，用https://demo.local访问，浏览器会警告证书不受信任，点击继续访问即可。
如果你希望浏览器不报警告，可以把自签名证书导入到“受信任的根证书颁发机构”。具体操作是：在证书管理界面导出证书为 .cer 文件，然后双击安装，选择“本地计算机”，手动选择“受信任的根证书颁发机构”存储位置，完成导入。重启浏览器后就不再警告了。
实操心得：自签名证书默认有效期只有一年，到期后需要重新创建。我建议在日历里设个提醒，免得某天突然访问不了还找不到原因。另外，某些浏览器对自签名证书的容忍度越来越低，如果遇到无法绕过的情况，可以考虑用本地 CA 工具生成证书，或者改用其他调试方式。
6. 常见问题与排查技巧实录
6.1 访问域名时出现 404 或 403
这是最常见的问题，排查思路按以下顺序进行。
先确认 hosts 映射是否生效。ping 域名看是否解析到 127.0.0.1。如果解析不对，检查 SwitchHosts 方案是否启用，或者手动刷新 DNS。
再确认 IIS 绑定是否匹配。检查站点的绑定里，主机名、端口、协议是否和你访问的 URL 完全一致。特别注意端口，如果 IIS 绑定的是 8080，你访问时不带端口就会走 80，自然找不到站点。
然后检查默认文档。403 通常是目录浏览被禁用且没有默认文档；404 是默认文档列表里没有你实际存在的入口文件。在 IIS 里双击“默认文档”确认。
最后检查物理路径权限。500.19 错误多半是权限问题，按照前面讲的方法给应用程序池账户添加读取权限。
6.2 SwitchHosts 切换后不生效
有时候勾选了方案，但 hosts 文件内容没变。原因可能有几个。
一是 SwitchHosts 没有以管理员权限运行。修改 hosts 文件需要管理员权限，如果 SwitchHosts 本身权限不足，写入会失败。右键 SwitchHosts 图标，选择“以管理员身份运行”。
二是系统 DNS 缓存没刷新。运行ipconfig /flushdns手动刷新。
三是 hosts 文件被其他程序锁定。某些安全软件会保护 hosts 文件，阻止外部修改。检查安全软件的设置，把 SwitchHosts 加入白名单。
四是 SwitchHosts 的方案内容格式有误。比如 IP 和域名之间用了中文空格，或者域名里有非法字符。检查一下内容，确保每行格式正确。
6.3 端口冲突导致站点启动失败
IIS 站点启动时提示“端口已被占用”，说明有其他程序在监听同一个端口。用netstat -ano | findstr :端口号找到占用进程的 PID，然后在任务管理器里根据 PID 找到对应程序，决定是关掉它还是给 IIS 换端口。
常见的端口占用来源包括：其他 Web 服务器（如 Nginx、Apache）、某些开发工具的内置服务器、聊天软件、下载工具等。我遇到过某下载工具默认占用 80 端口的情况，排查了半天才发现。
如果实在不想换端口，也可以把占用程序配置成其他端口，但有些程序不提供修改选项，那就只能给 IIS 换端口了。
6.4 应用程序池频繁回收导致首次访问慢
默认情况下，应用程序池闲置 20 分钟就会回收，下次访问时需要重新启动工作进程，导致首次请求响应很慢。本地开发时可以把闲置超时改成 0，禁用回收。
在 IIS 管理器选中应用程序池，右键“高级设置”，找到“闲置超时”改为 0，“定期时间间隔”改为 0，“禁用重叠回收”设为 True。这样工作进程会一直保持运行，访问速度稳定。
但要注意，禁用回收后如果站点代码有内存泄漏，进程会一直占用内存不释放。本地开发一般问题不大，如果发现内存占用异常增长，再手动回收一下即可。
6.5 常见问题速查表
| 现象 | 可能原因 | 排查方法 | 解决方式 |
|---|---|---|---|
| 域名无法解析 | hosts 未生效 | ping 域名 | 检查 SwitchHosts 方案，刷新 DNS |
| 404 Not Found | 默认文档缺失 | 检查 IIS 默认文档列表 | 添加入口文件名 |
| 403 Forbidden | 目录浏览禁用 | 检查目录浏览设置 | 启用目录浏览或添加默认文档 |
| 500.19 错误 | 权限不足 | 查看详细错误信息 | 给应用程序池账户添加权限 |
| 端口冲突 | 其他程序占用 | netstat 查端口 | 关闭占用程序或换端口 |
| 首次访问慢 | 应用程序池回收 | 检查闲置超时设置 | 改为 0 禁用回收 |
| HTTPS 证书警告 | 自签名证书不受信任 | 浏览器提示 | 导入受信任根证书或忽略警告 |
| 跨域请求失败 | CORS 未配置 | 浏览器控制台报错 | 后端添加 CORS 响应头 |
6.6 几个容易被忽略的细节
hosts 文件的编码问题。Windows 的 hosts 文件默认是 ANSI 编码，如果你用某些编辑器保存成了 UTF-8 带 BOM 的格式，可能导致解析异常。SwitchHosts 会自动处理编码，但如果你手动编辑过 hosts 文件，建议用记事本打开另存为 ANSI 编码。
域名后缀的选择。.local后缀在部分网络环境下会被 mDNS 协议拦截，导致解析异常。如果遇到这种情况，可以改用.test、.dev或者.localhost。其中.localhost是保留后缀，永远指向本机，不需要 hosts 映射也能用，但无法自定义子域名。.test是专门保留给测试用途的，比较推荐。
IIS 日志的位置。站点访问日志默认在C:\inetpub\logs\LogFiles下，按站点 ID 分目录存放。排查访问问题时，日志里的 sc-status（状态码）、sc-substatus（子状态码）、sc-win32-status（Windows 错误码）是重要线索。比如 404.3 表示 MIME 类型未映射，500.19 表示配置错误。
应用程序池的 identity。默认是 ApplicationPoolIdentity，但某些场景下需要改成 NetworkService 或自定义账户。比如访问网络共享路径时，ApplicationPoolIdentity 可能没有权限。改身份后记得同步调整文件系统权限。
SwitchHosts 的备份功能。它支持把方案导出为文件，建议定期备份一下方案配置。万一重装系统或者换电脑，导入备份就能快速恢复，不用重新一条条写。
7. 进阶技巧与效率提升
7.1 用命令行快速管理 IIS 站点
虽然图形界面方便，但有些操作命令行更快。以管理员身份打开 PowerShell，几个常用命令：
# 查看所有站点 Get-Website # 启动站点 Start-Website -Name "demo-site" # 停止站点 Stop-Website -Name "demo-site" # 重启应用程序池 Restart-WebAppPool -Name "demo-site-pool" # 查看应用程序池状态 Get-WebAppPoolState -Name "demo-site-pool"把这些命令存成脚本，需要时一键执行，比在界面里点来点去快得多。特别是重启应用程序池这个操作，调试代码时经常需要，用命令行效率提升明显。
7.2 SwitchHosts 配合脚本实现自动化
SwitchHosts 支持从命令行调用吗？严格来说它没有提供完整的 CLI，但你可以通过修改它的配置文件来实现一些自动化。配置文件在用户目录下的.SwitchHosts文件夹里，是 JSON 格式。你可以用脚本生成方案内容，然后让 SwitchHosts 重新加载。
另一种思路是绕过 SwitchHosts，直接用脚本操作 hosts 文件。比如写一个 PowerShell 脚本，根据参数切换不同的 hosts 内容块。但这样就没有 SwitchHosts 的界面和托盘快捷操作了，适合集成到自动化流程里。
7.3 多环境配置的命名规范
项目多了之后，域名和站点命名容易混乱。我建议采用统一的命名规范：
- 站点名：
项目名-环境，如demo-dev、demo-test - 域名：
项目名.环境后缀，如demo.local、demo-test.local - 应用程序池：
站点名-pool，如demo-dev-pool - SwitchHosts 方案：
项目名-环境，如demo-dev
这样从任何一个名字都能快速定位到对应的项目和环节，减少混淆。
7.4 性能优化的几个小调整
本地开发虽然对性能要求不高，但做一些小调整能让体验更顺畅。
启用静态内容压缩：在 IIS 里双击“压缩”，勾选“启用静态内容压缩”和“启用动态内容压缩”。这样返回的 HTML、CSS、JS 会被压缩，传输更快。
调整 HTTP 响应头：在“HTTP 响应标头”里可以设置缓存策略。本地开发建议禁用缓存，避免改了代码浏览器还读旧文件。可以在响应标头里添加Cache-Control: no-cache。
开启失败请求跟踪：在站点上双击“失败请求跟踪”，启用后可以记录详细的请求处理过程，排查 500 错误时特别有用。但会产生大量日志，问题解决后记得关掉。
7.5 团队协作时的配置同步
如果是团队开发，每个人的本地环境配置最好保持一致。SwitchHosts 的远程方案功能可以派上用场。把方案内容放到一个内部可访问的 URL 上，团队成员添加远程方案，指向这个 URL，就能自动同步映射规则。
IIS 的配置可以通过导出 applicationHost.config 来共享，但直接共享整个文件容易冲突。更好的做法是写一个配置脚本，新成员拉取代码后运行脚本自动创建站点和应用程序池。PowerShell 的 WebAdministration 模块提供了完整的 API，可以脚本化所有配置操作。
8. 我个人的一些实操体会
这套组合我用了好几年，从最初的磕磕绊绊到现在的顺手拈来，中间积累了不少经验。最大的体会是：配置一次，受益很久。前期花一两个小时把 IIS 和 SwitchHosts 配好，后面每个新项目只需要几分钟就能搭起一套完整的本地访问环境，比每次重新折腾集成包要省心得多。
另一个体会是不要怕命令行。IIS 的图形界面虽然友好，但很多批量操作和自动化场景还是命令行更高效。花点时间学几个常用的 PowerShell 命令，长期来看回报很高。
还有一点是做好记录。我专门维护了一个文档，记录每个项目的站点配置、端口分配、域名映射、应用程序池名称等信息。项目多了之后，没有记录很容易搞混。SwitchHosts 的方案名称和 IIS 的站点名称保持一致，也能减少认知负担。
最后，遇到问题先看日志。IIS 的日志、Windows 事件查看器、浏览器开发者工具，这三个地方能解决 90% 以上的问题。很多人一遇到报错就到处搜，其实答案就在日志里。养成看日志的习惯，排查效率会大幅提升。
这套方案后续还可以扩展，比如配合反向代理工具做更复杂的请求转发，或者结合容器技术做环境隔离。但就本地开发的基本需求而言，IIS 加 SwitchHosts 已经足够覆盖绝大多数场景了。
