IIS中为PHP站点添加虚拟目录时，别名与物理路径需匹配权限配置：ApplicationPoolIdentity必须对物理路径有读取+执行权，且需确保FastCGI处理程序继承或显式配置，否则.php文件将无法执行。
在 IIS 管理器中为 PHP 站点添加虚拟目录时，别名和物理路径必须匹配 PHP 运行权限
虚拟目录不是“挂个链接就完事”，它本质是 IIS 以特定用户身份访问另一个物理路径。如果 PHP 站点用的是默认应用池（如 DefaultAppPool），那该池的标识用户（通常是 ApplicationPoolIdentity）必须对虚拟目录所在文件夹有读取+执行权限。
常见错误现象：HTTP Error 500.19 - Internal Server Error，错误代码 0x80070005（拒绝访问），或页面空白但无日志——大概率是权限没给够。
- 右键站点 → 「添加虚拟目录」→ 输入别名（如
uploads），物理路径选目标文件夹（如D:\site\shared\uploads） - 点击「连接为」→ 选择「特定用户」→ 输入
IIS APPPOOL\DefaultAppPool（注意拼写，不能写成DefaultAppPool$或漏掉IIS APPPOOL\前缀） - 不要点「测试设置」就跳过：它只测连接通不通，不测 PHP 脚本能否执行；务必手动进该虚拟目录放一个
test.php（内容<?php echo 'ok'; ?>），再浏览器访问/uploads/test.php
PHP 站点下虚拟目录仍需继承 FastCGI 处理程序，否则 .php 文件直接下载或 404
IIS 不会自动把虚拟目录里的 .php 请求转发给 php-cgi.exe —— 它只认网站根目录或显式配置了处理程序的路径。虚拟目录默认沿用父站点的 handler 映射，但前提是父站点的 handler 是「全路径通配」且未被子级覆盖。
关键检查点：web.config 中的 <handlers> 是否作用于子路径？
立即学习“PHP免费学习笔记（深入）”；
- 若站点根目录已有全局 handler（如
name="PHP_via_FastCGI",path="*.php"），则虚拟目录内.php文件通常能正常执行 - 若不行，可在虚拟目录根新建
web.config，仅包含 handler 继承声明：<configuration> <system.webServer> <handlers> <remove name="PHP_via_FastCGI" /> <add name="PHP_via_FastCGI" path="*.php" verb="*" modules="FastCgiModule" scriptProcessor="C:\php\php-8.4.1\php-cgi.exe" resourceType="Unspecified" /> </handlers> </system.webServer> </configuration> - 绝对不要在虚拟目录里重复注册 FastCGI 应用（即不要在「FastCGI 设置」里多加一条
php-cgi.exe），那是服务器级配置，与虚拟目录无关
PHP8.4 的虚拟目录若含上传或写入操作，upload_tmp_dir 和 session.save_path 必须指向可写位置
PHP8.4 默认禁用 open_basedir 限制后，upload_tmp_dir 若仍指向 C:\Windows\Temp，而 IIS 用户无权写入，会导致 move_uploaded_file() 静默失败、$_FILES 为空。
这不是 IIS 配置问题，而是 PHP 运行时行为，但常被误判为虚拟目录路径错误。
- 打开对应 PHP 版本的
php.ini（比如C:\php\php-8.4.1\php.ini），确认以下两项： -
upload_tmp_dir = "C:\php\php-8.4.1\tmp"（建议设为 PHP 目录下的子文件夹，避免系统路径权限冲突） session.save_path = "C:\php\php-8.4.1\sessions"- 手动创建这两个目录，并赋予
IIS_IUSRS和IIS APPPOOL\DefaultAppPool「修改」权限 - 重启对应应用池（不是整个 IIS），让 php.ini 变更生效
虚拟目录本身不改变 PHP 版本绑定逻辑，但它放大了权限和路径配置的脆弱性——尤其是当多个 PHP8.4.x 子版本共存时，PHPRC 环境变量只控制 php.ini 加载，不控制 tmp 或 sessions 目录权限。这点最容易被忽略。
