AddType仅设置MIME类型（如application/x-httpd-php），浏览器据此识别文件类型；AddHandler才真正指定处理模块（如php7_module），二者必须同时配置，缺一不可，否则PHP脚本无法执行。
Apache 里 AddType 和 AddHandler 都得配对出现
只加 AddType application/x-httpd-php .php 不够，浏览器看到 MIME 类型只是“知道这是 PHP”，但服务器仍可能不调用 PHP 解析器；必须同时有 AddHandler application/x-httpd-php .php，才真正把请求交给 PHP 模块处理。
常见错误是只在 mime.types 里加了映射，或只在 .htaccess 里写了 AddType，却漏掉 AddHandler。两者缺一不可。
-
AddType告诉 Apache “.php 文件该标成什么类型” -
AddHandler告诉 Apache “标成这个类型的文件，该交给哪个模块处理” - 如果用了多版本 PHP（如 php81、php82），
AddHandler的模块名要严格匹配，比如AddHandler application/x-httpd-php82 .php
Nginx 中 types 块误删 php 映射会导致解析失败
Nginx 默认 mime.types 文件里包含 application/x-httpd-php php; 这一行。如果你自定义了 types 块（比如为了精简 MIME 列表），又没手动补上这行，Nginx 就会把 .php 当作 text/plain 返回——浏览器收不到 Content-Type: application/x-httpd-php，自然不触发解析，而是直接下载源码。
检查方法：运行 nginx -T | grep -A5 'types {'，确认输出中存在 application/x-httpd-php php;。
立即学习“PHP免费学习笔记（深入）”；
- 不要在
server或location块里写default_type text/plain;，它会覆盖所有未明确映射的扩展名 - 若用
include mime.types;，确保路径正确且文件可读；否则整个 MIME 映射失效 - 即使 FastCGI 配置全对，MIME 类型缺失也会让响应头变成
Content-Type: text/plain，phpinfo()页面显示为纯文本
phpinfo() 页面顶部 Server API 是关键线索
访问一个仅含 <?php phpinfo(); ?> 的文件，页面最上方的 Server API 字段直接说明当前 PHP 是如何被调用的：
- 显示
apache2handler→ Apache 直接加载了 PHP 模块，问题大概率出在AddHandler或目录权限 - 显示
CGI / FastCGI或FPM/FastCGI→ 请求已转发给 PHP-FPM，此时重点查 Nginx 的fastcgi_param SCRIPT_FILENAME是否指向真实路径 - 显示
cli→ 说明根本没走 Web 服务器，你可能是双击打开的文件，或用php -S启动的内置服务器但没配路由
如果页面完全空白或弹下载，说明请求压根没进 PHP，Server API 根本看不到——这时候别看 phpinfo()，先回去查 Web 服务器配置是否加载了 PHP 处理器。
浏览器开发者工具 Network 标签能快速定位响应头问题
刷新 PHP 页面，在浏览器按 F12 → Network → 点击那个 .php 请求 → 查看 Response Headers。重点关注三处：
-
Content-Type是不是application/x-httpd-php或text/html？如果是text/plain或空值，说明 MIME 配置失败 - 有没有意外出现的
Content-Disposition: attachment？那是 PHP 脚本自己输出的，不是服务器配置问题 -
Status是不是 200？如果是 502/503，说明 PHP-FPM 没通；如果是 404，检查root或alias路径是否拼错
这个步骤比反复重启服务更省时间——只要响应头不对，再怎么重装 PHP 都没用。
