同一份 PHP 代码，Windows 服务器上有两种跑法：IIS 通过 FastCGI 直接接管 PHP 进程，或者 IIS 只做门面，把请求转发给后面的 PHP 服务。两条路线的部署方式和性能特征都不一样。
## 路线一：IIS 加 FastCGI
FastCGI 是 Web 服务器与外部程序之间的常驻进程通信协议，IIS 收到 PHP 请求后交给一组复用的 php-cgi 进程处理。部署路径：装 IIS 角色时勾选 CGI 组件；解压 PHP 的非线程安全（NTS）包到 D:\php；在 IIS 的 FastCGI 设置里登记 php-cgi.exe 路径；php.ini 里开 cgi.fix_pathinfo 和常用扩展。验证就一个文件：
<?php phpinfo();
浏览器能看到配置详情表即通。
## 路线二：IIS 反向代理
IIS 装 URL Rewrite 和 ARR（Application Request Routing，应用请求路由模块）之后充当反向代理，把 PHP 请求整站转发给本机另一个监听端口的 PHP 运行服务，由后者用自己的进程模型处理并返回结果。IIS 这层只负责证书、压缩和静态文件，PHP 侧的并发模型独立于 IIS 的进程管理，升级扩展也不用动 IIS 配置。
## 性能差异从哪来
FastCGI 路线的开销在进程调度：每个请求在 IIS 与 php-cgi 进程之间转一手，Windows 上进程创建成本又偏高，并发一上来处理队列就明显变长。反向代理路线的 PHP 侧常用事件驱动的服务模型，并发上限更高，代价是多一层转发延迟和更多常驻内存。单机小站在日常流量下感知不到差别，压测到高并发才分出高下。
## 生产建议
低流量官网、内部系统，FastCGI 路线简单直接，出问题排查路径短，优先选它；并发压力大的业务站，反向代理路线更有余量，也方便以后把 PHP 层单独迁移出去。无论哪条路，opcache（PHP 的字节码缓存扩展）必须开，php.ini 里确认 opcache.enable=1，这一项带来的提速往往超过两条路线之间的差距。
还有一句实话：PHP 项目对 Windows 的适配从来不是第一优先级，项目从零起步、平台可以自由选的话，Linux 加同款软件栈是更省心的默认项；被既有环境定死在 Windows 上时，再按上面的标准在两条路线里挑。