iis应用程序池高级配置需匹配应用特性：.net clr版本须严格对应框架版本，asp.net core进程内托管选v4.0；托管管道模式首选integrated；cpu限制需配合适当操作（如throttle或killw3wp）；队列长度宜按实际流量调整（200–500）；标识优先用applicationpoolidentity并授最小权限。
IIS 应用程序池的高级配置直接影响网站稳定性、资源利用率和请求响应质量。关键不在于堆参数调得多高，而在于匹配应用实际行为——比如高并发但轻量的 API 服务，和内存密集型报表系统，配置逻辑完全不同。
.NET 版本与托管管道模式
这两项必须协同设置，否则会直接导致 500 错误或静态文件无法访问。
-
.NET CLR 版本：严格对应应用程序编译所用的框架版本。ASP.NET Core 应用若使用进程内托管（
hostingModel="inprocess"），此处应选v4.0（即使运行在 .NET 6+ 上，IIS 仍通过兼容层识别）；纯 .NET Framework 应用则选 v2.0 或 v4.0；“无托管代码”仅适用于纯静态站点或 PHP 等非托管场景。 - 托管管道模式：推荐始终使用 Integrated。Classic 模式已过时，它将 ASP.NET 请求交由独立 ISAPI 处理，绕过 IIS 全局模块（如 URL 重写、认证模块），导致功能割裂。只有极少数依赖旧版 HttpModule 的遗留系统才需回退。
CPU 与内存资源控制
避免“一刀切”设限，重点防范单个异常应用拖垮整台服务器。
-
CPU 限制（%）：设为非零值（如 70）后，需同步配置 限制操作。选
NoAction仅记录日志；选Throttle会主动降低该工作进程优先级；选KillW3wp则强制回收进程——后者适合内存泄漏风险高的老系统。 - 队列长度：默认 1000 对多数业务偏高。若站点常突发流量且后端处理慢，可降至 200–500，并配合前端负载均衡器启用健康检查，让超载节点自动摘除，比返回 503 更友好。
- 32 位支持：仅当应用明确依赖 32 位 DLL（如某些旧数据库驱动、COM 组件）时才启用。64 位系统上开启此选项会禁用大内存寻址能力，反而限制性能。
启动与回收策略
目标是减少用户感知的中断，而非单纯延长进程寿命。
-
启动模式：设为
AlwaysRunning是实现“零秒冷启动”的前提，但必须搭配 自动启动提供程序（如自定义预热脚本或 WCF 自动启动）；否则只是空转进程，浪费资源。 - 闲置超时：默认 20 分钟。对内部管理后台可设为 0（永不停止），但对外网公开的高可用站点，建议保留 5–10 分钟，防止僵尸进程长期驻留。
-
禁用配置轮换回收：在
web.config的<aspnetcore></aspnetcore>节点内添加<handlersetting name="disallowRotationOnConfigChange" value="true"></handlersetting>，可避免全局applicationHost.config修改（如新增日志规则）触发所有站点重启。
身份与安全边界
用最小权限原则隔离应用，比防火墙更底层有效。
-
应用程序池标识：默认
ApplicationPoolIdentity已足够安全。它为每个池创建独立虚拟账户（如IIS APPPOOL\MyApiPool），无需手动建 Windows 用户。仅当应用需访问网络共享或 SQL Server 时，才需切换为自定义域账户并授予权限。 -
物理路径权限：确认该虚拟账户对网站目录有
读取 & 执行权限，对日志目录有写入权限。用icacls命令验证：icacls "C:\MySite" /q /c /t /is /grant "IIS APPPOOL\MyApiPool":(OI)(CI)RX。
