Composer install 本身不会触发 PHP-FPM 重启；所谓重启实为部署脚本、自定义钩子（如 post-install-cmd 中的 systemctl restart）、OPcache 未刷新或监控误判所致，需通过 PID 对比和日志排查真因。
Composer install 为什么会触发 PHP-FPM 重启？
它不会。Composer install 本身完全不接触 PHP-FPM 进程，也不会发送任何信号或调用系统服务管理命令。所谓“运行 composer install 导致 PHP-FPM 重启”，一定是其他环节在 composer install 后被自动触发，或者你误将「部署流程中的后续动作」归因于 Composer。
常见被误认为是 Composer 引起的 FPM 重启场景
这些操作常和 composer install 写在同一行脚本或 CI/CD 步骤里，但责任不在 Composer：
- 部署脚本中紧跟着执行了
systemctl restart php-fpm或service php8.3-fpm restart—— 这才是真正重启者 - 某些自动化部署工具（如 Envoyer、Deployer）在
composer install成功后默认调用opcache_reset()或触发 reload，而你的监控恰好把进程重启时间戳对齐到了 Composer 结束时刻 - 你在本地用
php -S启动的开发服务器被 kill 掉了，误以为是 FPM；FPM 本身只响应 Web 请求，不监听 CLI 命令 - Mac 上通过 Homebrew 安装的 PHP 自带 launchd 配置，
php-fpm被设为 keep-alive 模式，kill 掉后会自动拉起 —— 和 Composer 完全无关
如何确认是不是 Composer 在“偷偷”重启 FPM？
最直接的办法是隔离执行：
- 先执行
ps aux | grep php-fpm记下主进程 PID - 再单独运行
composer install --no-scripts --no-plugins（禁用所有钩子） - 立刻再次执行
ps aux | grep php-fpm，看 PID 是否变化 - 如果 PID 不变，说明 FPM 没重启；若变了，检查是否同时有其他进程在操作服务（比如 systemd 日志：
journalctl -u php-fpm -n 20）
注意：composer install 默认会执行 post-install-cmd 脚本，如果你的 composer.json 里写了 "post-install-cmd": ["systemctl restart php-fpm"]，那问题就出在这里 —— 不是 Composer 的错，是你自己配的钩子干的。
立即学习“PHP免费学习笔记（深入）”；
真正需要关注的关联点：OPcache 和 autoload 文件变更
虽然 Composer 不重启 FPM，但它生成的新 vendor/autoload.php 和 autoload_static.php 会被 OPcache 缓存。旧缓存未清除时，PHP-FPM 仍加载老类——这容易被误判为“FPM 没生效”或“重启失败”。此时该做的不是找谁重启了 FPM，而是确认 OPcache 是否已重载：
- 检查是否在部署后调用了
opcache_reset()（需确保 PHP 配置允许该函数） - 或手动清空 OPcache：访问一个含
<?php opcache_reset(); ?>的 PHP 文件（仅限调试环境） - 或验证
opcache_get_status()['opcache_enabled']是否为true，且opcache_get_status()['scripts']中包含新 autoload 文件路径
真正的风险点不在重启本身，而在于你以为“install 完了就完事”，却忘了 OPcache 不会自动感知文件变更——它只认内存快照，不读磁盘mtime。
