composer clear-cache 不会清除 php opcache 缓存，它仅清理 composer 全局缓存目录（如 ~/.composer/cache）下的 files/、repo/、vcs/ 子目录，与 php 运行时字节码缓存完全无关；opcache 需通过重启服务或调用 opcache_reset() 单独刷新。
composer clear-cache 不会清除 PHP OPcache 缓存，它只管 Composer 自己的下载缓存（~/.composer/cache），和运行时代码加载完全无关。
OPcache 和 Composer 缓存是两套完全独立的机制
很多人误以为清了 composer clear-cache 就能立刻看到代码变更生效，结果改完 src/ 文件却还是旧逻辑——问题根本不在 Composer，而在 PHP 的 OPcache。Composer 负责“把类文件下载、解压、生成自动加载映射”，OPcache 负责“把已加载的 PHP 字节码缓存进内存，跳过重复编译”。两者不共享数据、不互相通知。
-
composer dump-autoload只刷新vendor/autoload.php和相关映射，不碰 OPcache -
composer install或update会重写vendor/，但 OPcache 仍可能继续执行旧字节码 - 即使你删了整个
vendor/并重装，只要 OPcache 没刷新，PHP 进程仍可能从缓存里拉出旧类定义
如何真正让代码变更生效：必须操作 OPcache
OPcache 的刷新方式取决于你的 PHP 运行模式，没有统一命令，得看环境：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Web 服务器（如 Apache + mod_php）：重启 httpd 或 php-fpm 进程是最直接有效的方式；仅 reload 不一定清 OPcache，尤其在某些配置下
- FPM 模式（Nginx + php-fpm）：
sudo systemctl restart php*-fpm（如php8.2-fpm），或sudo service php8.2-fpm restart - CLI 场景（如跑 PHPUnit 或 Artisan 命令）：OPcache 默认对 CLI 关闭，所以一般不用管；但如果你手动启用了（
opcache.enable_cli=1），就得用opcache_reset()函数或重启 CLI 进程 - 开发中想免重启？可在代码开头加
if (function_exists('opcache_reset')) opcache_reset();，但仅限开发环境，禁止上生产
为什么 composer clear-cache 后还看不到新代码
这不是 Composer 的 bug，也不是配置错，而是典型的“缓存层级混淆”：
- 现象：改了
app/Service.php，跑了composer dump-autoload，甚至clear-cache，浏览器里还是旧行为 - 原因：PHP-FPM worker 进程仍在运行，OPcache 里的
Service.php字节码没失效，请求进来直接执行缓存版本 - 验证方法：访问
http://your-site/opcache-reset.php（内容为<?php opcache_reset(); ?>），再刷新页面——如果立刻生效，就确认是 OPcache 问题 - 注意：
opcache.validate_timestamps=0（生产常用）会让 OPcache 完全忽略文件修改时间，此时必须重启或调用opcache_reset()
容易被忽略的关键点
OPcache 的行为高度依赖 php.ini 配置，而不同环境默认值差异很大：
-
opcache.revalidate_freq设为 60 秒？意味着最多等待 60 秒才检查文件是否更新——不是实时的 -
opcache.max_accelerated_files太小？会导致新文件挤掉旧缓存，但不会主动刷新旧条目 - Docker 环境里，如果 PHP 镜像没暴露 OPcache 管理接口，
opcache_reset()可能被禁用（disable_functions里含该函数） - 某些云平台（如 Laravel Forge、Plesk）提供一键“Clear OPcache”按钮，本质就是调用
opcache_reset()或重启服务，比手动更可靠
