部署PHP项目时，Composer更新代码后需重置OPcache以避免加载旧类文件。因OPcache缓存了旧的自动加载映射和类文件，仅运行composer install不足以生效，必须通过重启PHP-FPM、调用opcache_reset()或reload服务等方式清除缓存，确保新版本代码正确加载。
当使用 Composer 管理 PHP 项目的依赖并在生产环境中运行 PHP-FPM 时，OPcache 的存在可能导致部署新版本后仍加载旧的类文件或旧的自动加载映射。这会引发类未找到、方法不存在等运行时错误。为确保新代码正确生效，必须在部署后重置 OPcache，使 PHP-FPM 加载更新后的 Composer 自动加载机制和新引入的类文件。
理解 Composer 与 OPcache 的协作机制
Composer 负责生成 autoload.php 和相关的自动加载映射（如 classmap、psr-4 映射），这些文件决定了 PHP 如何定位并包含类文件。PHP-FPM 使用 OPcache 将已编译的 PHP 脚本（包括这些 autoload 文件和业务类）缓存在共享内存中，以提升性能。
问题出现在：即使你通过 git pull 更新了代码，并且 Composer 已重新生成 autoload 文件，OPcache 可能仍在使用旧版本的缓存。这意味着：
- 旧的类文件被继续使用
- 新增的类无法被发现
- 命名空间变更未生效
因此，部署新代码后，仅运行 composer install 是不够的，还必须让 OPcache 清除旧缓存。
立即学习“PHP免费学习笔记（深入）”；
部署后重置 OPcache 的方法
有几种方式可以触发 OPcache 重置，选择合适的方法取决于你的服务器配置和部署流程。
1. 重启 PHP-FPM 进程最直接有效的方式是重启 PHP-FPM 服务。这会清空所有进程的 OPcache 缓存。
命令示例：
sudo systemctl restart php-fpm
或根据你的系统：
sudo service php7.4-fpm restart
适用于拥有服务器控制权限的场景，缺点是会造成短暂的服务中断（通常很短）。
如果你无法或不想重启服务，可以在部署脚本中调用 PHP 的 opcache_reset() 函数。该函数会清除当前 PHP 进程的 OPcache。
注意：PHP-FPM 通常有多个工作进程，opcache_reset() 只影响调用它的那个进程。要真正生效，需要确保所有工作进程都被“轮询”重置，或配合 FPM 的 reload 操作。
创建一个重置脚本 clear_opcache.php：
<?php
if (function_exists('opcache_reset')) {
opcache_reset();
echo "OPcache has been reset.\n";
} else {
echo "OPcache is not enabled.\n";
}
?>
然后在部署完成后访问该脚本（可通过 CLI 或 HTTP 触发）：
php clear_opcache.php3. 优雅地重载 PHP-FPM
使用 reload 而非 restart，可实现零停机部署：
sudo systemctl reload php-fpm
reload 会通知主进程重新加载配置并启动新工作进程，旧进程处理完请求后退出。新进程加载新的 PHP 文件并构建新的 OPcache，避免访问旧类文件。
结合部署流程的最佳实践
建议将 OPcache 重置集成到自动化部署流程中，例如使用 Deployer、Capistrano 或自定义脚本。
典型流程如下：
- 拉取最新代码
- 执行 composer install --no-dev -o（生成优化的自动加载）
- 执行数据库迁移等操作
- 重启或重载 PHP-FPM 服务
如果使用共享主机或无法重启服务，可结合 opcache_invalidate() 针对特定文件失效缓存，但管理复杂，不推荐用于全量更新。
基本上就这些。关键是意识到 Composer 更新不会自动刷新 OPcache，必须主动干预以确保新代码生效。选择适合你环境的方式，在每次部署后清理缓存，就能避免因缓存导致的神秘错误。
