企业官网建设流程全解析

简介：一份系统讲述PHP与MySQL在IIS服务器上综合应用的专业文献，源自2002年期刊论文，面向Web开发工程师、数据库管理员及技术选型人员。该文从开发简单、运行高效、经济可行等角度出发，将PHP+MySQL组合与CGI、ISAPI、ASP等常见方案进行对比，阐明了在Windows 2000/IIS 5.0环境下的独特优势，为在微软服务器平台上构建Web数据库应用提供了清晰思路。资源仅含1个PDF文件，压缩包整体118KB，内容精炼，可直接作为技术参考。文中详细覆盖了PHP的ISAPI扩展配置步骤，包括通过Internet服务管理器添加.php映射、指定可执行文件、用phpinfo()验证配置，以及MySQL的安装设置、客户端mysql.exe远程连接用法；同时以具体代码示范了mysqli_connect()建立连接、检测连接状态等关键实现技术，并指出了硬件与系统环境要求。已有91人学习下载，适合具备一定Web开发基础、希望在IIS下快速落地PHP+MySQL应用的读者深入查阅。

1. 把 PHP 和 MySQL 跑在 Windows 的 IIS 上，为什么还值得折腾

很多开发者手里都有一份名为《PHP及MYSQL在IIS服务器上的应用》的 PDF 老教程，但照着操作时往往卡在第一步：IIS 默认只认 ASP.NET，PHP 文件下载下来双击却打不开，MySQL 装好了 PHP 却报“未定义函数 mysqli_connect”。这套组合的难点不在 PHP 本身，而在 IIS 对 PHP 的请求转发机制、FastCGI 配置，以及 PHP 与 MySQL 之间的扩展启用。本文会从选型讲到落地，覆盖 FastCGI 部署、php.ini 必调参数、MySQL 连接方式、IIS 应用程序池权限坑，最后给出一套排查和验收技巧。适合在 Windows Server 或 Windows 10/11 上用 IIS 承载 PHP 项目的场景，尤其是公司内网系统、老项目迁移和需要与 ASP.NET 站点共存的情况。

2. 在 IIS 上运行 PHP 的选型与 FastCGI 原理

2.1 为什么 IIS 不能直接“运行” PHP，FastCGI 解决了什么

IIS 本身是一个 HTTP 服务器，它只负责接收请求、解析 HTTP 协议、返回响应。至于某个文件扩展名对应的内容如何处理，IIS 依赖“处理程序映射”（Handler Mapping）来决定。默认情况下，IIS 只内置了静态文件和 ASP.NET 的处理程序，.php文件没有对应的处理程序，请求进来只会被当作静态文件返回源码或者直接 404。

要让 IIS 支持 PHP，本质上是让 IIS 把.php请求转发给一个能执行 PHP 脚本的进程。目前主流的转发方式有三种：CGI、FastCGI 和 ISAPI。CGI 是每次请求都启动一个新进程，性能差且已经被 IIS 默认禁用；ISAPI 是微软早年推荐的 DLL 扩展方式，但 PHP 官方在新版本中已不再提供可靠的 ISAPI 支持。最终被 PHP 官方和微软共同推荐的是 FastCGI 模式。

FastCGI 的原理是：PHP-CGI 进程常驻内存，IIS 通过一个协议与这些常驻进程通信。当请求到达时，IIS 把环境变量和请求体通过 FastCGI 协议发给 PHP-CGI，PHP 执行完毕后再通过同一通道返回结果。因为进程不退出，省去了反复 fork 和初始化 PHP 引擎的开销，性能比 CGI 高出一个数量级。IIS 从 7.0 开始内置了 FastCGI 模块，不需要额外安装第三方组件，这是选择 FastCGI 的最大理由。

# 查看 IIS 是否已安装 FastCGI 模块（管理员权限 PowerShell） Get-WindowsFeature Web-CGI # 如果 Status 为 Available 或 Installed，说明 FastCGI 支持已经就绪

以上命令在 Windows Server 上检查Web-CGI功能状态。IIS 的 FastCGI 模块属于 Web-CGI 角色的一部分，未安装时需要先启用。

2.2 PHP 版本选择：Thread Safe 还是 Non-Thread Safe

从 PHP 官网下载 Windows 版本时，会发现同一版本提供两个压缩包：nts（Non-Thread Safe）和ts（Thread Safe）。这个选择直接取决于你打算用哪种方式让 PHP 跑在 IIS 上。

在 FastCGI 模式下，PHP 是以单进程多请求的方式运行的吗？并不是。FastCGI 模式下 PHP-CGI 进程本身是单线程的，IIS 会维护一个 PHP-CGI 进程池，并发请求通过多个 PHP-CGI 进程来承载。在这种场景下，PHP 的线程安全与否并不影响运行，但官方明确建议 FastCGI 使用 Non-Thread Safe 版本，因为 NTS 版本在 FastCGI 下性能稍好且更稳定。

如果你选择的是 Apache Windows 版，Apache 的mod_php模块方式要求使用 Thread Safe 版本。但既然标题锁定在 IIS 上，直接选择nts版本即可。注意 PHP 8.x 之后官方不再提供 PHP 7.x 的 Windows 安装包，下载时认准php-8.x.x-nts-Win32-vs16-x64.zip这类命名格式。

2.3 用 PHP Manager 工具快速配置 FastCGI

手动配置 IIS 的 FastCGI 需要改applicationHost.config文件，操作繁琐且容易出错。常见的做法是使用 PHP Manager for IIS，这是一个微软官方出品的 IIS 扩展，它以图形界面方式完成 PHP 注册、处理程序映射、php.ini 定位等操作。

PHP Manager 安装完成后，打开 IIS 管理器，在站点根节点下会看到一个 PHP Manager 图标。点击后选择“Register new PHP version”，定位到你的php-cgi.exe路径，它会自动完成以下三件事：注册 FastCGI 应用程序、添加.php处理程序映射、校验 php.ini 是否存在。用这种方式把基础配置搭好，远比手动改配置文件更可靠。

<!-- 手动注册 FastCGI 和 PHP 处理程序映射的配置片段（位于 applicationHost.config） --> <fastCgi> <application fullPath="C:\PHP\php-cgi.exe" monitorChangesTo="C:\PHP\php.ini" activityTimeout="90" requestTimeout="300" instanceMaxRequests="10000"> <environmentVariables> <environmentVariable name="PHP_FCGI_MAX_REQUESTS" value="10000" /> </environmentVariables> </application> </fastCgi> <handlers> <add name="PHP_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" resourceType="Unspecified" requireAccess="Script" /> </handlers>

fullPath指向 php-cgi.exe 的绝对路径，monitorChangesTo让 IIS 监控 php.ini 变化并自动重启 PHP 进程，PHP_FCGI_MAX_REQUESTS控制单个 PHP-CGI 进程处理多少请求后自动回收，避免内存泄漏累积。requireAccess="Script"表示只允许执行脚本，静态文件请求不受影响。

2.4 php.ini 中与 IIS 运行强相关的必调参数

PHP 安装目录下默认有php.ini-development和php.ini-production两个模板文件。通常的做法是把php.ini-development复制为php.ini，然后重点调整下面几个参数。

; php.ini 关键配置 extension_dir = "C:\PHP\ext" cgi.fix_pathinfo = 1 fastcgi.impersonate = 1 date.timezone = Asia/Shanghai

extension_dir必须指向 PHP 解压目录下的ext文件夹，否则后续启用 mysqli、pdo_mysql 扩展时都会报找不到 DLL。cgi.fix_pathinfo=1是 FastCGI 模式下的关键配置，它让 PHP-CGI 正确处理 PATH_INFO 形式的 URL。fastcgi.impersonate=1让 PHP 进程模拟 IIS 认证后的客户端身份，配合 NTFS 权限可以实现按用户隔离访问。date.timezone不设置的话，PHP 运行时会抛出的时区警告并影响时间函数。

; 启用 MySQL 相关扩展 extension=mysqli extension=pdo_mysql

把extension=mysqli和extension=pdo_mysql前面的分号去掉，这是 PHP 连接 MySQL 的基础。修改完 php.ini 后需要重启 IIS 才能生效，可以在 IIS 管理器右侧点击“重新启动”，或者在命令行执行iisreset。验证 PHP 是否正常工作的方式是新建一个phpinfo.php文件放在站点根目录，写入 Volatile 内容后用浏览器访问，如果能看到 PHP 信息面板，说明 FastCGI 链路已经打通。

3. PHP 连接 MySQL 的配置、代码与常见误区

3.1 PHP 连接 MySQL 的三种方式选型

PHP 连接 MySQL 主要有三种 API：mysql、mysqli和PDO_MySQL。其中mysql扩展在 PHP 7.0 已被彻底移除，现在还在写mysql_connect()的代码在 PHP 8 上直接报“调用未定义函数”。mysqli是面向 MySQL 的专用扩展，支持面向对象和面向过程两种写法。PDO_MySQL是 PHP 数据库抽象层的一个驱动，好处是更换数据库时不用改写业务代码，但代价是会多一层封装，部分 MySQL 特性需要用$pdo->exec()或$pdo->query()配合原生 SQL 来绕过。

对于新项目，我一般会建议使用 PDO，因为它的参数绑定机制更规范，能有效降低 SQL 注入风险。对于维护老项目，如果代码里全是mysqli_query()这种写法，就没必要强行切换到 PDO，保持风格统一更重要。在 IIS 环境下两种扩展都可以正常工作，关键是 php.ini 里必须启用对应的扩展。

<?php // 使用 PDO 连接 MySQL 的完整示例 $dsn = 'mysql:host=127.0.0.1;port=3306;dbname=testdb;charset=utf8mb4'; $user = 'web_user'; $pass = 'SecurePass123'; try { $pdo = new PDO($dsn, $user, $pass, [ PDO::ATTR_ERRMODE => PDO::ERRMODE_EXCEPTION, PDO::ATTR_DEFAULT_FETCH_MODE => PDO::FETCH_ASSOC, PDO::ATTR_EMULATE_PREPARES => false, ]); echo "连接成功，MySQL 版本：" . $pdo->query('select version()')->fetchColumn(); } catch (PDOException $e) { // 生产环境不要输出 $e->getMessage() 给终端用户 error_log($e->getMessage()); exit('数据库连接失败，请稍后重试'); } ?>

ATTR_EMULATE_PREPARES设置为 false 表示使用 MySQL 原生的预处理语句，可以避免 PDO 默认的模拟预处理方式在特殊字符下产生的 SQL 注入隐患。ATTR_ERRMODE设为异常模式后，SQL 执行出错会抛出异常，方便统一捕获。连接失败时将错误信息写入 PHP 日志而不是直接展示给用户，这是一个值得坚持的习惯。

3.2 MySQL 8.0 认证插件兼容问题

MySQL 8.0 默认的认证插件是caching_sha2_password，而 PHP 7.4 以下版本的 mysqli 和 PDO_MySQL 驱动默认不支持这种加密方式，连接时会报Authentication plugin 'caching_sha2_password' cannot be loaded错误。

解决这个问题有两种路径。第一种是修改 MySQL 用户的认证插件为mysql_native_password：

-- 将指定用户切换回传统认证插件 ALTER USER 'web_user'@'localhost' IDENTIFIED WITH mysql_native_password BY 'SecurePass123'; FLUSH PRIVILEGES;

第二种是升级 PHP 版本到 7.4 以上，PHP 7.4 起官方已支持caching_sha2_password。但如果你的生产环境因为历史原因锁定在 PHP 7.3 或更低版本，第一种方法就是唯一出路。这里有个容易被忽略的点：修改认证插件只影响该用户的登录方式，不会改变数据库编码和排序规则，不要顺手把库表编码也改了，以免引发乱码。

3.3 IIS 环境下 MySQL 连接超时的定位思路

在 IIS 上部署 PHP 应用后连接 MySQL 超时，最常见的原因不是 MySQL 本身的问题，而是防火墙没有放行 3306 端口。由于 IIS 和 MySQL 在同一台机器的场景比较多，很多人下意识认为不存在网络问题。但 Windows 防火墙默认会阻止外部访问 3306 端口，如果你从另一台机器访问 MySQL，就需要在防火墙入站规则中放行该端口。

# 在 Windows 防火墙中放行 MySQL 3306 端口 New-NetFirewallRule -DisplayName "Allow MySQL 3306" -Direction Inbound -LocalPort 3306 -Protocol TCP -Action Allow

确认网络层面的连通性后，再检查 MySQL 自身的绑定地址。MySQL 8.0 的my.ini中bind-address如果设置为127.0.0.1，则只有本机能连接，局域网内其他机器即使防火墙放行也无法访问。改成0.0.0.0表示监听所有网卡。验证连通性时可以用Test-NetConnection -ComputerName 目标IP -Port 3306快速判断端口是否可达。

4. IIS 应用程序池、权限设置与常见报错处理

4.1 应用程序池的经典池与集成管道选择

IIS 7.5 之后应用程序池有两种托管管道模式：集成模式和经典模式。集成模式下，所有请求都会经过托管模块的完整管道处理，静态文件也会走一遍 ASP.NET 管线。经典模式则完全由 IIS 原生处理静态文件，只有动态请求才交由对应的 ISAPI 扩展或 FastCGI 处理程序执行。

对于纯 PHP 项目，应用程序池的管道模式选经典模式即可，因为 PHP 不走 ASP.NET 管线，集成模式只会增加无谓的模块加载开销。需要特别注意的一点是，应用程序池的“.NET CLR 版本”应当设为“无托管代码”。如果选成.NET CLR v4.0，IIS 会在每次 PHP 请求时尝试加载 CLR 环境，既拖慢速度，又可能在权限不足时抛出异常。这个设置在 IIS 管理器中对应“应用程序池”右键属性中的 `.NET CLR 版本”下拉框。

4.2 应用程序池权限设置失败的 0x80005000 错误

搜索引擎里“iis应用程序池权限设置失败,请手动为其设置localsystem权限未知错误(0x80005000)”是一条高频检索词，这个错误的本质是 IIS 元数据库权限出现了问题。0x80005000对应E_ADS_UNKNOWN_ERRROR，通常发生在尝试修改应用程序池的高级设置时，系统无法写入 IIS 配置存储。

这个错误常见于从旧版本 IIS 迁移或注册表权限被改动过的机器。修复方式分两步：第一步，打开“服务”管理器，确认IISADMIN服务和W3SVC服务都在运行；第二步，用管理员身份打开命令提示符，执行以下命令重置 IIS 的配置权限：

# 重置 IIS 配置存储的权限 icacls C:\Windows\System32\inetsrv\config /reset /t /c /q # 注册 IIS 配置组件 %windir%\system32\inetsrv\appcmd.exe migrate config

icacls的/reset参数会把inetsrv\config目录下的 ACL 重置为系统默认值，/t表示递归处理子目录，/c让命令遇到错误时继续执行，/q关闭成功信息输出。appcmd migrate config会重新生成缺失的配置节。做完后再去应用程序池的高级设置里改身份，问题大概率能解决。如果不生效，可以检查 Windows 事件查看器中IIS-W3SVC-WP日志，定位具体的错误模块。

4.3 FastCGI 进程回收与应用程序池超时的关系

PHP 跑在 IIS 上偶尔出现“服务不可用”或 500 错误，很多时候不是 PHP 代码的问题，而是 FastCGI 进程被回收了。IIS 有几种机制会杀掉 PHP-CGI 进程：应用程序池的闲置超时（默认 20 分钟）、FastCGI 的activityTimeout和requestTimeout，以及进程数限制。

activityTimeout表示 FastCGI 进程在指定秒数内没有收到任何请求活动就会被终止，requestTimeout表示单个请求最多执行多久。对于需要执行长任务的 PHP 脚本，这两个值用默认的 90 秒和 300 秒可能不够。调整方法是在 IIS 管理器中点开“FastCGI 设置”，选中 PHP 进程项，点击“编辑”，把活动超时调大到 300，请求超时调大到 600。

<fastCgi> <application fullPath="C:\PHP\php-cgi.exe" activityTimeout="300" requestTimeout="600"> </application> </fastCgi>

同时在应用程序池的“高级设置”中，将“空闲超时”改为 0 分钟，意思是不因闲置而回收进程。不过这里有个权衡：进程常驻意味着内存占用量会保持在一个水平，如果你在跑多个 PHP 站点，需要根据服务器内存大小决定是否这样做。不建议盲目把回收机制全关掉，对于内存只有 4GB 的服务器，内存泄漏带来的稳定性风险远大于进程回收的短暂卡顿。

4.4 伪静态与 URL Rewrite：WordPress 类 PHP 应用必须处理的一环

在 IIS 上部署 WordPress 或其他依赖伪静态的 PHP 框架时，需要安装 URL Rewrite 模块。这个模块是 IIS 对 Apache 的 mod_rewrite 的等价物，它读取站点根目录或子目录中的web.config文件中的重写规则。

<!-- web.config 中的 WordPress 伪静态规则 --> <configuration> <system.webServer> <rewrite> <rules> <rule name="WordPress" patternSyntax="Wildcard"> <match url="*" /> <conditions> <add input="{REQUEST_FILENAME}" matchType="IsFile" negate="true" /> <add input="{REQUEST_FILENAME}" matchType="IsDirectory" negate="true" /> </conditions> <action type="Rewrite" url="index.php" /> </rule> </rules> </rewrite> </system.webServer> </configuration>

这段规则的含义是：如果请求的文件在物理路径上不存在，则把所有请求重写到index.php。{REQUEST_FILENAME}是 IIS 的服务器变量，matchType="IsFile"判断是否真实文件，negate="true"表示取反，也就是“不是文件也不是目录”才走重写规则。如果不配置这一段，WordPress 的固定链接（Permalink）设置成“文章名”后，所有非首页链接都会返回 404。

5. 进阶用法：在 IIS 上用命令行排查 PHP 与 MySQL 的隐蔽问题

当 IIS 站点已经能跑通 PHP 和 MySQL 时，真正考验经验的是那些浏览器里看不到的故障。这里有一个值得掌握的技巧：用命令行直接调用php-cgi.exe来绕过 IIS 做单点测试，快速定位问题出在 PHP 自身、PHP 与 MySQL 的连接、还是 IIS 转发配置上。

# 用命令行模式测试 PHP 是否正确加载扩展 C:\PHP\php.exe -m # 查看具体扩展的加载状态 C:\PHP\php.exe --ri mysqli

php.exe -m列出所有已加载的模块。如果mysqli没有出现在列表里，说明 php.ini 中扩展启用有问题。--ri mysqli会输出该扩展的版本和配置信息，如果报错则说明扩展文件与 PHP 版本不匹配，常见的如把 PHP 8.2 的php_mysqli.dll拷贝到了 PHP 7.4 的 ext 目录下。这一步通常能筛掉一大半扩展加载问题。

# 指定 php.ini 路径运行测试脚本，绕过 IIS 直接执行 C:\PHP\php.exe -c C:\PHP\php.ini -r "print_r(mysqli_get_client_info());"

-r参数表示直接执行后面的 PHP 代码，-c指定 php.ini 的路径。如果此时返回了 MySQL 客户端库版本号，说明 PHP 的 MySQL 扩展已经就绪。再把mysqli_get_client_info()换成实际的连接代码，就能判断数据库连接失败的根源。这个办法在处理一访问 PHP 页面就白屏或 500 错误，但事件查看器里没有明确报错时尤其有效。还可以配合 Windows 的系统监测工具resmon，观察php-cgi.exe进程的数量和 CPU 占用，确认诊断结果与实际运行情况吻合。

本文还有配套的精品资源，点击获取