双击打开php文件必然显示源码，因触发file://协议，不经过服务器或php解释器；php是服务端语言，无服务端参与则无法执行，与apache/nginx配置无关。
双击打开 PHP 文件必然显示源码，这不是配置问题
双击 .php 文件触发的是 file:// 协议，浏览器直接读取本地文件内容，不经过任何服务器或 PHP 解释器。PHP 是服务端语言，没有服务端参与就不可能执行——这跟 Apache、Nginx 或 PHP-FPM 配置无关，是根本性限制。
常见误操作包括：
- 用资源管理器双击
test.php，地址栏显示file:///home/user/test.php或file://C:\xampp\htdocs\test.php - 在 VS Code 里点“Open with Live Server”，但该插件默认只起静态 HTTP 服务，不支持 PHP
- 把 PHP 文件放在桌面或文档目录，而非 Web 服务器根目录（如
/var/www/html或XAMPP/htdocs）
用 php -S 启动内置服务器是最简验证方式
无需安装 Apache/Nginx，只要系统已装 PHP（运行 php -v 能输出版本即表示可用），就能快速启动一个可执行 PHP 的本地服务。
操作步骤：
- 终端进入 PHP 文件所在目录，例如
cd /path/to/myproject - 执行
php -S localhost:8000（端口可自选，8000 是常用值） - 浏览器访问
http://localhost:8000/test.php，此时才会真正执行 PHP
注意：php -S 不支持重写规则（如 Laravel 的 .htaccess），也不处理静态资源自动映射，仅用于基础功能验证和开发调试。
Apache/Nginx 显示源码，大概率是 fastcgi_pass 或模块没连上
如果已通过 http://localhost/test.php 访问却仍见源码，说明 Web 服务器收到了请求，但没交给 PHP 处理。关键检查点不是“有没有装 PHP”，而是“有没有把请求转给 PHP”。
典型断点：
- Apache：确认
libphp.so已加载（httpd -M | grep php），且配置中有AddType application/x-httpd-php .php - Nginx：检查
location ~ \.php$块内是否含fastcgi_pass，并确认php-fpm进程正在运行（systemctl is-active php-fpm） - 响应头中
Content-Type是text/plain而非text/html，说明服务器压根没调用 PHP，只是返回了原始文件
文件名或路径错误也会导致“假性解析失败”
看起来像配置问题，实际是请求根本没命中 PHP 文件。这类问题隐蔽性强，容易反复折腾配置却无效。
高频陷阱：
- 文件真实扩展名是
test.php.txt（Windows 默认隐藏扩展名），用ls -la或属性查看确认 - URL 访问的是
http://localhost/test.PHP（大写），而服务器配置通常只匹配小写.php - PHP 文件放在
/home/user/project/，但 Apache 根目录设为/var/www/html，请求根本没落到该文件 - 使用符号链接，但 Web 服务器未启用
FollowSymLinks权限（Apache）或disable_symlinks off（Nginx）
最稳妥的验证方式：在 Web 根目录下新建一个 info.php，内容只有 <?php phpinfo(); ?>，然后访问对应 URL —— 如果仍显示源码，说明环境链路断裂；如果显示 PHP 信息页，那问题一定出在你的代码或路径上。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
