php-fpm是fastcgi进程管理器，非脚本执行命令；它作为常驻服务接收nginx/apache转发的http请求，调用php解释器执行对应.php文件，需通过web服务器触发而非直接运行php-fpm script.php。
php-fpm 不是直接执行脚本的命令
php-fpm 本身是个常驻进程（FastCGI 管理器），它不接受 php-fpm script.php 这样的调用。你不能像 php script.php 那样直接用它跑单个脚本——这是最常见的误解。
它的职责是接收 Web 服务器（如 Nginx/Apache）转发的 HTTP 请求，再调用 PHP 解释器执行对应的 .php 文件。所以“在 php-fpm 模式下执行脚本”，本质是让 Web 服务器触发它。
- 直接运行
php-fpm命令只会启动守护进程，不会执行任何脚本 - 试图用
php-fpm /path/to/script.php会报错：Unknown option -/ 或类似提示 - 若只想测试脚本逻辑，仍该用
php /path/to/script.php（CLI 模式），和 php-fpm 无关
想让 php-fpm 执行某个脚本，得走 HTTP 请求路径
最典型的做法：配好 Nginx + php-fpm，把脚本放到 Web 根目录，然后用 curl 或浏览器访问。
例如，假设脚本在 /var/www/html/test.php，Nginx 已配置 fastcgi_pass 127.0.0.1:9000，且 php-fpm 正在监听该地址：
curl http://localhost/test.php
这时请求被 Nginx 转发给 php-fpm，后者加载并执行 test.php —— 这才是“在 php-fpm 模式下执行”的真实路径。
- 确保 php-fpm 的
www.conf中listen = 127.0.0.1:9000（或 socket 路径）与 Nginx 配置一致 - 脚本里用
$_SERVER['REQUEST_METHOD']或php_sapi_name()可验证当前确实是fpm-fcgi模式 - 注意权限：php-fpm worker 用户（如
www-data）必须有读取脚本和相关文件的权限
调试时怎么确认脚本真被 php-fpm 执行了
光看页面输出不够，因为 CLI 和 fpm 下某些行为不同（比如 $_SERVER 内容、工作目录、扩展加载状态）。可靠方式是主动打日志或查进程。
- 在脚本开头加：
file_put_contents('/tmp/phpfpm.log', "pid:".getmypid()." sapi:".php_sapi_name()."\n", FILE_APPEND); - 执行后检查
/tmp/phpfpm.log，看到sapi:fpm-fcgi才算成功 - 用
ps aux | grep php-fpm观察是否有 worker 进程在运行，再结合lsof -i :9000确认监听状态 - 如果返回 502 Bad Gateway，大概率是 Nginx 没连上 php-fpm（端口不通、socket 权限不对、php-fpm 没启动）
本地开发想快速验证，别硬套生产配置
没必要为跑一个脚本去配完整 Nginx+php-fpm。更轻量的方式是用 PHP 自带的内置服务器模拟，但它不是 php-fpm —— 注意区分。
真正想测 php-fpm 行为（比如 session 处理、opcache 行为、ini_set() 是否生效），就得走真实链路。这时候建议：
- 用 Docker 快速拉起标准环境：
docker run --rm -v $(pwd):/var/www/html -p 8080:80 php:8.2-apache（虽然用的是 apache，但原理相通） - 或用现成工具如 Laravel Valet / DDEV，它们底层就是自动配好 Nginx + php-fpm
- 避免手动改
php.ini后忘记重启 php-fpm：改完必须执行sudo systemctl reload php8.2-fpm（版本号按实际调整）
很多人卡在 reload 不生效，其实是因为改了错误的 ini 文件（CLI 和 fpm 加载的配置路径不同），用 php-fpm -t 和 php-fpm -i | grep 'Loaded Configuration File' 能准确定位。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
