应使用 post-autoload-dump 钩子而非 post-install-cmd 调用 opcache_reset()，因后者时 autoloader 尚未生成、opcache 未缓存应用代码；前者在 vendor/autoload.php 写入完毕、类映射就绪后执行，才能真正清空有效缓存。
post-install-cmd 里调用 opcache_reset() 会失败
因为 post-install-cmd 执行时，PHP 的 autoloader 还没写入磁盘，vendor/autoload.php 可能尚未生成，更别说 opcache 已加载这些文件。此时执行 php -r 'opcache_reset();' 虽不报错，但实际什么也没清——opcache 里压根没缓存你的应用代码。常见现象是：部署后仍看到旧的路由、配置或类行为，误以为清缓存生效了。
真正能清到 opcache 的时机是 post-autoload-dump
这个钩子在 vendor/autoload.php 完整写入、所有类映射就绪后触发，此时 opcache 才有可能已 warm up 过（尤其在 CI 构建中配合 --optimize-autoloader）。实操建议：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json的scripts中定义："post-autoload-dump": ["@php -r "if (function_exists('opcache_reset')) { opcache_reset(); echo 'opcache cleared.\n'; } else { echo 'opcache extension not loaded.\n'; }""] - 不要依赖
opcache_invalidate()逐个刷新——它只对已加载的脚本有效，而新安装的包文件大概率还没被 PHP 加载过 - 若项目使用 Docker 多阶段构建，确保运行该脚本的构建阶段已启用
opcache扩展（检查php -m | grep opcache）
生产环境别在 post-autoload-dump 里硬清 opcache
线上服务通常跑在 FPM 或 CLI 模式下，opcache_reset() 只重置当前 PHP 进程的缓存，对其他 worker 进程无效；FPM 下还可能因进程复用导致部分 worker 仍用旧字节码。更稳妥的做法是：
- 部署后通过信号或管理接口重启 FPM：
kill -USR2 $(cat /var/run/php/php8.1-fpm.pid) - 或在构建阶段禁用 opcache（
opcache.enable=0），上线后再由运维统一启用并 warmup - 若必须用脚本触发，改用
curl -X POST http://localhost/opcache-reset.php（需前置部署一个带鉴权的 reset endpoint）
验证 opcache 是否真被清掉
光看命令输出没用。部署后立刻检查：
-
php -r "print_r(opcache_get_status()['scripts']);"—— 确认关键文件的timestamp是最新修改时间 - 访问一个含
__FILE__或date_default_timezone_set()的测试路由，观察是否反映最新代码 - 注意：opcache 默认不缓存 CLI 模式脚本，所以本地
composer install后在终端里跑opcache_reset()对 web 请求完全无影响
