把 Node.js 部署到 IIS 这件事很多人一听第一反应是没必要本地一条node app.js就能跑为什么要折腾 IIS但如果你在公司内网维护过 Windows 服务器就会知道情况完全不是这样。团队要求统一走 IIS 管理端口、绑定域名、挂证书运维体系里没有单独的 Node 进程管理工具这时候把 Node 应用“塞进”IIS 就成了刚需。我当年第一次做这个事把网上教程翻了几十篇结果卡在 IIS 模块版本、应用池权限和 web.config 这些细节上好几天很多教程都是“装完 iisnode 就能跑”实际操作全是坑。这篇我按自己跑通整套流程的顺序把 Node.js 的安装环境、IIS 的开启方式、托管模块的选择、web.config 的配置、应用池和站点绑定全部拆开讲最后再把高频报错一次性列清楚。适合刚接触 Windows 服务器、正准备把第一个 Node 项目部署上去的同学也适合想从老方案迁移的人。1. 部署前的思路为什么要把 Node.js 放到 IIS 上1.1 命令行直接跑不香吗谈谈 IIS 托管的真实价值如果只是本地开发命令行直接跑完全没问题。可一旦放到服务器上裸命令行跑 Node 会遇到一连串问题窗口一关进程就没了机器重启后没人帮你把它拉起来进程崩溃之后也不会自动恢复端口被谁占用得自己排查管理多个 Node 服务时更是混乱。这些都是运维层面的现实问题不是你代码写得好就能绕开的。IIS 在这里的价值是“托管”而不是“运行”。你可以把 IIS 理解成一个酒店前台Node 应用是住客客人不需要自己去大街上找吃的前台会负责安排房间、送水、处理投诉。用 IIS 托管 Node 之后Node 进程由 IIS 的工作进程管理服务统一拉起崩溃了会自动重启开机也能自动恢复HTTP 请求由 IIS 统一接收再转交给 Node 处理日志走 IIS 的规范格式域名和 HTTPS 证书也在同一个地方管理。这套集成能力才是你花时间折腾部署的真正原因。所谓“把 Node.js 部署到 IIS”本质上是让 IIS 成为 Node 进程的前置宿主。它不改变你写 Node 的方式只是在外面包了一层进程管理和请求转发。理解这一点后面所有配置就都顺了。1.2 三条技术路线怎么选iisnode、httpPlatformHandler、反向代理部署方式网上说法很杂稍不注意就被带偏。我按自己的实践经验归纳成三条路线。方案核心原理优点缺点适用场景iisnode在 IIS 里注册一个 ISAPI 处理程序请求通过命名管道交给 Node和 IIS 集成最细能控制 Node 进程数量和回收策略维护频率不高和新版 Node 的兼容性有时有坑老项目已在用 iisnode不想大改httpPlatformHandler微软官方托管模块由 IIS 拉起 node.exe 进程并转发请求官方持续维护支持新 Node 版本崩溃自动拉起配置简单多进程扩展需要自己另想方案稳定成型的教程相对少新项目首选IIS 反向代理Node 自己监听一个端口IIS 用 URL Rewrite 转发代码层面改动最小Node 生态原样保留排障最直观需要额外用 PM2 或 NSSM 守护 Node 进程团队已经习惯 PM2 管理 Node 服务我的建议很直接如果是新项目优先选httpPlatformHandler。它是微软现在官方主推的托管方式既能满足“让 IIS 统一管理进程”的核心诉求又不像 iisnode 那样动不动就版本不对位。文章主线就按这个方案走最后一章再补反向代理路线的选型和配置。1.3 需要的物料清单动手前先把东西备齐免得装到一半卡住。一台 Windows 服务器或本机Windows Server 2016/2019/2022Win10/11 也能做本地模拟。Node.js LTS 安装包.msi 或 zip 绿色版都行。IIS 功能系统自带Web 服务器角色。httpPlatformHandler 1.2 x64 安装包微软官网下载。URL Rewrite 模块后面 HTTPS 跳转和反向代理方案要用。一个 Express 应用手写最小示例即可。一个具有管理员权限的账号。可选7-Zip 或任一解压工具处理绿色版 Node 时用得上。有了这张清单后面就不会频繁停下来找东西。2. 环境安装从零准备一台能跑 Node 的 IIS 服务器2.1 安装 Node.js版本选择、PATH、以及两个高频报错下载 Node.js 时认准官网nodejs.org首页的LTS 版本不要图新鲜用 Current 版。LTS 稳定性和生态兼容性都有保障服务器上跑应用不是追新的时候。安装包默认路径是C:\Program Files\nodejs\我习惯手动改成纯英文且无空格的目录比如D:\Nodejs或C:\nodejs。为什么有些原生模块和脚本解析路径时对空格敏感在 IIS 托管环境下更容易出幺蛾子干脆从源头避开。装的时候留意勾选“Add to PATH”这样命令行才能直接识别node和npm。装完以后新开一个 PowerShell 窗口验证node -v npm -v这里强调“新开窗口”是因为 PATH 环境变量修改只对新进程生效旧窗口里敲命令仍然会提示找不到。绿色版是另一种思路有些公司电脑不让装全局软件只能解压。把 zip 包解压到D:\nodejs然后手动把D:\nodejs加到系统 PATH 环境变量里效果和 msi 安装一样。热搜里那个“nodejs 免安装环境配置”指的就是这个。这一节单独讲两个高频报错因为实在太常见了第一个安装时报错 2203。错误编号 2203 通常和 Windows Installer 临时目录权限有关杀毒软件或安全策略经常横插一脚。处理顺序以管理员身份重新运行安装包清理C:\Windows\Temp和%TEMP%目录重启 Windows Installer 服务再不行就改用 zip 绿色版反而干净利落。第二个npm 命令通不过提示类似“无法加载文件 ... npm.ps1因为在此系统上禁止运行脚本”。这是 PowerShell 执行策略默认不允许运行.ps1脚本导致的不是 npm 坏了。两个解法要么直接用 CMD 窗口跑npm -v绕开 PowerShell 的限制要么在当前用户下放开脚本执行权限Set-ExecutionPolicy -Scope CurrentUser RemoteSigned输入Y确认即可。这个报错在热搜里出现的频率非常高属于“老手遇不到新手遇到两眼一抹黑”的典型问题。2.2 启用 IIS图形界面和 PowerShell 两种方式Windows 服务器上启用 IIS最标准的路子是“服务器管理器 → 添加角色和功能”一路下一步勾选Web 服务器(IIS)。注意别只勾最外层建议把“常见 HTTP 功能”里的静态内容、默认文档、HTTP 错误以及“应用程序开发功能”下的 ISAPI 扩展、ISAPI 筛选器、CGI 都勾上。这些功能现在看着多余以后装模块、排错时少很多麻烦。Win10/11 作为本地开发机的话去“控制面板 → 程序 → 启用或关闭 Windows 功能”勾选“Internet Information Services”同样建议把“应用程序开发功能”和“Web 管理工具”下的子项勾上。热搜里那个“server2019 iis 添加进度不动”的问题我在 Server 2019 上遇到过不止一次。图形界面卡在进度条时直接开一个管理员 PowerShell 跑命令Install-WindowsFeature -Name Web-Server -IncludeManagementTools这条命令会把 IIS 核心角色和管理工具一起装好比图形界面稳。Windows 客户端系统可以用 DISM 命令dism /online /enable-feature /featurename:IIS-WebServerRole /featurename:IIS-ManagementConsole装完以后浏览器访问http://localhost看到 IIS 默认欢迎页就说明基础环境通了。2.3 安装 httpPlatformHandler 托管模块去微软官网搜“HttpPlatformHandler v1.2”下载 x64 版本。安装前确认 IIS 已经装好否则安装器会直接报错退出。安装完成后打开 IIS 管理器找到站点级别的“处理程序映射”应该能看到名为httpPlatformHandler的条目。如果看不到先在管理员命令行执行iisreset /restart重启 IIS 再刷新。这一步容易漏很多教程没提导致后面 web.config 里写了 handler 却始终不生效。顺手把 URL Rewrite 模块也装上。它虽然在主线方案里不是必需但后面做 HTTPS 跳转、反向代理时基本都会用到提前装好省得来回折腾。3. 项目落地让 IIS 真正把 Node 应用托管起来3.1 准备一个最小可跑的 Express 应用先在服务器上建一个项目目录我习惯放在C:\inetpub\wwwroot\nodeapp这个路径后续会作为 IIS 站点的物理路径。在目录里初始化项目npm init -y npm install express然后新建app.js内容如下const express require(express); const os require(os); const app express(); const PORT process.env.PORT || 3000; app.get(/, (req, res) { res.send(Hello from Node.js on IIS! Host: ${os.hostname()}); }); app.listen(PORT, () { console.log(Node app listening on port ${PORT}); });这里最关键的一行是const PORT process.env.PORT || 3000。在 IIS 托管环境里端口号通常由宿主进程通过环境变量注入代码里读到什么就监听什么写死 3000 反而可能出现端口冲突或请求无法到达。加上|| 3000是为了命令行直接跑时也能自测。写完后先不要碰 IIS直接在项目目录执行node app.js浏览器访问http://localhost:3000。能正常显示页面说明应用本身没问题。这一步相当于把“代码问题”和“IIS 配置问题”预先切分开了后面排障时思路会非常清晰。3.2 web.config 逐行拆解httpPlatformHandler 参数详解接下来在项目根目录新建web.config。这个文件是 IIS 的站点级配置入口整个站点要不要被 Node 接管、怎么接管都靠它说了算。?xml version1.0 encodingUTF-8? configuration system.webServer handlers add namehttpPlatformHandler path* verb* moduleshttpPlatformHandler resourceTypeUnspecified / /handlers httpPlatform processPathC:\nodejs\node.exe argumentsapp.js stdoutLogEnabledtrue stdoutLogFileC:\logs\node.log startupTimeLimit20 requestTimeout00:02:00 environmentVariables environmentVariable nameNODE_ENV valueproduction / /environmentVariables /httpPlatform /system.webServer /configuration逐个说handlers节点把进入站点的 HTTP 请求交给httpPlatformHandler处理。path*表示不管哪个路径都交给它verb*表示 GET、POST 等所有请求方法都包含。processPath指向node.exe的绝对路径。我强烈建议和前面一样安装在无空格的纯英文路径能避开一堆莫名其妙的坑。argumentsNode 进程启动参数入口文件是app.js。stdoutLogEnabled和stdoutLogFile把 Node 进程打印到控制台的信息写进日志文件。你代码里的console.log、报错堆栈都会出现在这里排查问题第一站就是它。日志目录需要提前建好且要有写权限。startupTimeLimitIIS 启动 Node 进程后等待它就绪的最长时间单位秒。默认 20机器性能差或依赖加载慢就调大到 60。requestTimeout单个请求的最大处理时间。如果应用里有大数据导出、批量计算这类长耗时接口默认配置可能不够按需加大。environmentVariables通过环境变量注入配置。这里设置的NODE_ENVproduction在代码里通过process.env.NODE_ENV就能读到。改完保存后IIS 会自动检测到 web.config 变化并重新加载不需要手动重启。但如果改了多遍始终没生效回收一次应用池是最快的复位方式。3.3 目录权限与日志目录设置web.config 配好只是第一步权限没给对照样访问不了。在C:\inetpub\wwwroot\nodeapp目录上右键 → 属性 → 安全添加两个账号IUSR和IIS_IUSRS勾选“读取和执行”。这两个是 IIS 默认的工作进程身份给它们读取权限IIS 才能读到你项目里的文件、把请求转给 Node 进程。日志目录同样要处理。比如按照上面配置里的C:\logs\node就要给IIS_IUSRS加上“修改”或“写入”权限否则 Node 进程往日志文件里写内容时会被系统拒绝而表现很可能只是页面无响应不会直接报“权限不足”给你看。最后讲一个安全习惯如果 Node 应用需要写文件比如上传目录或者运行日志单独给对应的子目录加“修改”权限就行不要整个站点根目录开写权限。真被攻破时写权限范围越小损失越小。3.4 老项目兼容iisnode 传统配置写法如果你的老项目已经在用 iisnode切到 httpPlatformHandler 之前先看懂老配置长什么样?xml version1.0 encodingUTF-8? configuration system.webServer handlers add nameiisnode pathapp.js verb* modulesiisnode / /handlers iisnode nodeProcessCommandLineC:\nodejs\node.exe / /system.webServer /configurationiisnode 的机制是直接把app.js映射成处理程序入口Node 代码里同样需要监听process.env.PORT只不过这个 PORT 来自 iisnode 创建的命名管道。这套方案最大的问题是维护频率低遇到新版 Node 或某些原生模块时容易报 500。我的建议很简单不是已经在生产环境跑着的老项目就别主动选它遇到坑也不要死磕把 web.config 换成 3.2 节的写法代码基本不用改。4. 应用池、站点绑定与上线让应用可以被外网访问4.1 为 Node 应用创建专用应用池走到这一步IIS 已经能把 Node 进程拉起来了接着要给它安排一个独立的应用池避免和服务器上其他站点互相干扰。在 IIS 管理器左侧点击“应用程序池”右侧“添加应用程序池”名称NodeAppPool名字随意。.NET CLR 版本选“无托管代码”。托管管道模式集成。选“无托管代码”这个点我要单独解释一下。Node 进程本身不跑在 .NET 运行时上选了托管版本反而会给进程额外加载 CLR既没必要又浪费内存。热搜里“iis 中没有。net8”这类问题多半也是被“应用程序池必须要选一个 .NET 版本”这个惯性思维带偏了Node 项目根本不需要。添加之后还要改几个高级设置进程模型 → 标识保持默认的ApplicationPoolIdentity即可如果项目特殊需求要指定账号再单独改。进程模型 → 闲置超时分钟改为0。默认 20 分钟超过这个时间没有请求IIS 会回收 Node 进程下次访问会经历冷启动特别慢。应用里有内存缓存或 WebSocket 连接的话被回收更是灾难。回收 → 固定时间间隔改为0。默认 1740 分钟29 小时会定时回收一次同样会中断 Node 进程。后台任务、定时器这类逻辑最怕这种“悄悄的重启”。启动模式改为“始终运行”。IIS 8.5 以上支持配合预热让进程常驻避免第一个请求卡半天。这些设置弄完后It’s time to move to the site.4.2 添加站点、绑定域名与端口IIS 管理器左侧“网站”上右键 → “添加网站”站点名称NodeApp。应用程序池选择刚建好的NodeAppPool。物理路径C:\inetpub\wwwroot\nodeapp。默认绑定是“全部未分配”IP、端口 80、主机名不填。如果服务器上已经有站点占用了 80 端口会提示冲突先停掉默认站点或换一个端口。只让本机访问的话IP 地址绑定为127.0.0.1就够了。想让内网或公网访问必须绑定“全部未分配”或具体的内网/公网 IP同时确认 Windows 防火墙入站规则放行了对应端口。云服务器还要到云控制台的安全组里放行端口。这一步单独拿出来讲是因为我把“服务器 IIS 网站外网打不开”这类问题排查到最后十次有八次都是防火墙或安全组在挡路而不是 IIS 本身的问题。有域名的场景更简单站点“绑定”里添加一个node.example.com主机名再到 DNS 那边解析到服务器 IP。同一个 IP 加多个站点、每个站点不同主机名IIS 会按主机名路由请求这也是很多人选择 IIS 管理多站点的原因。配置完成后浏览器访问绑定地址能看到Hello from Node.js on IIS!就说明整个链路通了。如果打不开直接跳到第 5 章对照排查。4.3 HTTPS 证书绑定与 HTTP 跳转IIS 之所以在 Windows 生态里经久不衰HTTPS 配置相对简单是很重要的原因。打开 IIS 管理器 → 服务器根节点 → “服务器证书”右侧选择“导入”选中你的.pfx证书文件输入私钥密码。管理型证书颁发机构给的一般是 pfx如果是 pem/crt/key 那一套可以先用 OpenSSL 转成 pfx 再导入。导入成功后到站点“绑定”里添加类型httpsIP 地址全部未分配端口443主机名如果不填这个证书会匹配该 IP 上所有 https 请求SSL 证书选择刚导入的证书HTTP 自动跳 HTTPS 也顺手做了。安装 URL Rewrite 模块后在web.config的system.webServer节点内加规则rewrite rules rule nameHTTPS Redirect stopProcessingtrue match url(.*) / conditions add input{HTTPS} pattern^OFF$ / /conditions action typeRedirect urlhttps://{HTTP_HOST}/{R:1} redirectTypePermanent / /rule /rules /rewrite这段规则的意思是只要当前请求是 HTTP就永久重定向到 HTTPS 的相同地址。内网环境用自签证书测试没问题但生产环境不要用自签证书信任问题会伴随你整个部署周期。导入证书时报“指定的网络密码不正确”九成是私钥密码复制错了要么是 pfx 导出时用的加密算法和当前服务器版本不兼容。4.4 静态文件与 Node 路由共存问题httpPlatformHandler 配置里我写了path*也就是所有请求都交给 Node。这样做对纯 Node 应用最省心express.static(public)能处理静态文件。但如果你希望.css、.js、图片这些静态资源由 IIS 原生能力处理别让 Node 承担这部分压力就需要调整 handler 规则。在handlers里把规则拆开handlers add nameStaticFile path*.js;*.css;*.png;*.jpg;*.gif;*.ico;*.svg;*.woff;*.woff2 verb* modulesStaticFileModule resourceTypeFile / add namehttpPlatformHandler path* verb* moduleshttpPlatformHandler resourceTypeUnspecified / /handlersIIS 会按处理程序列表的顺序逐个尝试匹配。把静态文件规则放在前面命中后缀的请求直接由 IIS 返回文件没命中的再往下走交给 httpPlatformHandler 转发给 Node。顺序反了会导致静态文件也被 Node 接管然后再到 Node 里找对应文件演变成 404 或性能问题。实际项目里静态资源少就直接让express.static处理配置最简单静态资源多、并发大再拆到 IIS 层。5. 高频报错排查把这些坑提前替你踩完5.1 高频报错速查表我把经过实战检验的问题整理成表覆盖了热搜和日常部署里出现频率最高的几类。场景 / 报错可能原因解决办法npm.ps1无法加载提示禁止运行脚本PowerShell 执行策略限制用 CMD 跑 npm或执行Set-ExecutionPolicy -Scope CurrentUser RemoteSigned安装 Node.js 报 2203 错误Windows Installer 临时目录权限异常或被杀毒拦截管理员身份运行清理 Temp关杀毒或改用 zip 绿色版IIS 报“执行此操作时出错文件名 inetsrv\config...”配置文件被占用、只读或权限不足管理员身份重试确认文件未只读临时停 W3SVC 服务检查杀毒Server 2019 IIS 添加进度不动图形界面等待角色服务超时改用Install-WindowsFeature -Name Web-Server -IncludeManagementTools创建站点的应用池下拉框找不到 .NET 8被“选择 CLR 版本”的惯性思维带偏Node 项目选“无托管代码”不依赖 .NET 运行时设置应用池标识报 0x80005000图形界面写配置失败常因权限或组策略限制管理员身份重跑或直接用 appcmd 命令修改标识站点返回 500 或 500.1000Node 进程没起来或 web.config 错误先命令行node app.js自测再看 stdout 日志确认 node.exe 路径正确站点返回 502.3请求超时或 Node 进程崩溃调大requestTimeout看事件查看器确认日志目录可写修改代码后不生效httpPlatformHandler 托管的 Node 进程常驻回收对应应用池或执行iisreset /restart外网打不开本机能开防火墙、云安全组、或绑定地址错误放行入站端口检查安全组确认绑定的是“全部未分配”打开目录显示文件列表或 403默认文档配置或请求没被 Node 接管确认应用有/路由检查 web.config handleriisnode 方案下静态文件 404通配符映射把所有请求都转给了 Node切 httpPlatformHandler或按后缀拆分 handler关于 0x80005000 这个报错我再补充一个实用命令。图形界面改不了应用池标识时用管理员命令行执行%windir%\system32\inetsrv\appcmd set apppool NodeAppPool /processModel.identityType:LocalSystem把NodeAppPool替换成你的应用池名称LocalSystem也可以换成NetworkService。这个命令能绕开图形界面的写入问题直接改配置十有八九能解决。5.2 快速定位问题在 IIS 层还是 Node 层排障最重要的是先分清楚问题出在哪一层否则容易瞎折腾。我自己的排查顺序固定是四步第一步在项目目录手动执行node app.js直接访问 Node 自监听端口。能访问说明代码和依赖都没问题这一步都报错那就先修代码别去动 IIS。第二步Node 层确认没问题再用 IIS 站点的地址访问。此时如果报错看 web.config 的stdoutLogFile日志Node 进程的启动报错和运行堆栈都在里面。第三步看 IIS 日志。默认路径在C:\inetpub\logs\LogFiles\W3SVC*\日志里能看到 HTTP 状态码。4xx说明请求到了 IIS 但被拒5xx说明请求到了 IIS 但后端处理失败502/503基本指向网关或进程问题。第四步打开 Windows 事件查看器 → Windows 日志 → 应用程序找node.exe或w3wp.exe的崩溃记录。这一步能看到系统层面的错误信息比如加载模块失败、内存不足等。这套流程能解决九成以上的部署问题。比到处搜“报错代码”管用得多。5.3 老版 iisnode 专项问题老项目切 httpPlatformHandler 之前如果还在用 iisnode这几个坑要提前知道第一位数必须匹配。Node 是 32 位还是 64 位iisnode 模块也要对应位数装反了进程起不来报错还很难看懂。第二通配符映射后所有请求都进 Node静态文件容易 404这时要参考 4.4 节的 handler 拆分。第三WebSocket 支持需要额外安装 IIS WebSocket Protocol 功能否则前端的长连接会一直连不上。遇到这些坑我的建议是干脆迁方案。替换 web.config 为 httpPlatformHandler 写法代码里保持process.env.PORT不变应用本身几乎不用动。6. 从“能跑”到“跑得稳”托管后的进阶优化6.1 环境变量与多环境配置应用跑通只是开始生产环境要考虑配置管理。在 web.config 的httpPlatform节点里environmentVariables可以用来注入数据库连接、Redis 地址、第三方密钥等环境变量。environmentVariables environmentVariable nameNODE_ENV valueproduction / environmentVariable nameDB_HOST value192.168.1.10 / /environmentVariables代码里统一用process.env.DB_HOST读取不写死任何环境相关的值。开发、测试、生产多套环境部署时每套环境的站点各自维护一份 web.config代码只需要一份。要注意 web.config 修改会触发应用池回收线上环境不要在请求高峰期频繁改动。6.2 用 PM2 / NSSM 做进程守护反向代理方案的补充如果团队更习惯用 PM2 管理 Node 服务可以走反向代理路线。Node 应用继续监听自己的端口比如 3000IIS 只负责接收外部请求并转发。IIS 侧需要安装 URL Rewrite 和 ARRApplication Request Routing启用代理功能然后加一条转发规则把所有请求重写到http://127.0.0.1:3000/{R:1}。Node 进程的守护交给 PM2npm install -g pm2 pm2 start app.js --name nodeapp pm2 save pm2 startupWindows 服务方式可以用 NSSMnssm install NodeApp C:\Program Files\nodejs\node.exe C:\inetpub\wwwroot\nodeapp\app.js这个方案的好处是 Node 进程的启停、日志、崩溃重启都沿用 Node 生态工具团队迁移成本低代价是 IIS 和 Node 之间存在两层维护体系。两种方案没有绝对优劣看团队习惯。我个人在 Windows 服务器上更倾向 httpPlatformHandler少一层服务少一份运维负担。6.3 日志、监控与健康检查部署完成不代表一劳永逸。日志和监控是维护阶段最值得投入的部分。IIS 日志默认记录每次请求的时间、客户端 IP、请求路径、状态码用来分析访问量和错误率足够。Node 进程自己的输出通过stdoutLogFile收集。生产环境建议在应用里用日志库输出 JSON 格式包含时间戳、请求 ID、错误堆栈排查问题时能直接按关键字检索效率和看白茫茫一片的console.log完全不同。健康检查也是我强烈建议做的给应用加一个/health接口返回简单的 JSON 状态外部监控系统每隔几十秒请求一次一旦连续失败就自动回收应用池或重启 IIS。这个方法成本极低但能有效缩短故障发现时间。另外IIS 的“失败请求跟踪”功能Failed Request Tracing对排查 500 错误非常有用。可以在站点层面配置跟踪规则指定哪些 HTTP 状态码需要记录详细过程然后重放问题请求就能看到请求在 IIS 管道里从进入到离开的全过程精确定位是 handler 没匹配上、权限不够还是进程没有起来。我个人在实际操作中的体会是部署 Node 到 IIS 真正难的不是“让页面跑起来”而是把进程生命周期、日志、权限这三件事理顺。一旦理顺IIS 的可靠性确实比裸命令行高得多尤其是运维交接的时候接管方不需要懂 Node 的启动细节一切按 IIS 的标准流程走就行。最后再分享一个小技巧改完 web.config 后如果觉得没生效先在 IIS 管理器里把对应应用池回收一下再刷新页面能省掉很多“明明改了半天却没变化”的烦躁。上生产之前记得先把C:\Windows\System32\inetsrv\config\applicationHost.config备份一次我习惯把备份放到独立目录万一配置改崩一份文件拖回去就能还原比在图形界面里一点点重配快太多了。