composer apcu自动加载缓存需同时满足：apcu扩展启用（apcu.enabled=1）、apcu.stat=0、执行composer dump-autoload -o --apcu；仅缓存类名→路径映射，不加速文件加载，cli与web缓存隔离，验证须用apcu_fetch()查键存在。
Composer 的自动加载缓存（APCu）不是开箱即用的功能，必须手动触发且依赖严格的运行时条件；不满足任一前提，composer dump-autoload --apcu 会静默失败，apcu_fetch() 查不到键，类加载速度毫无提升。
APCu 扩展和配置是否真正生效
CLI 和 Web SAPI 的 php.ini 很可能不同，而 Composer 运行在 CLI 下，所以只看 phpinfo() 页面没用。必须用命令确认：
- 执行
php -m | grep apcu，有输出才说明扩展已加载 - 执行
php -i | grep 'apcu.enabled'，值必须是1（不是On） - 执行
php -i | grep 'apcu.stat'，值必须是0；设为1时 APCu 会每次检查文件 mtime，自动加载器直接跳过缓存 - 执行
php -i | grep 'Loaded Configuration File'，确认你改的是 CLI 实际加载的php.ini，不是 Apache 或 Nginx 的那个
什么时候执行 --apcu，以及它到底缓存什么
--apcu 不是 install 或 update 的子选项，也不能靠 "optimize-autoloader": true 自动启用。它只在 dump-autoload 阶段起作用，且只生成两类缓存键：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer-autoload-classmap（对应autoload_classmap.php） -
composer-autoload-psr4（对应autoload_psr4.php） - 它不缓存
require、include或任何文件内容，只加速“类名 → 文件路径”的映射查找 - 所以必须配合
-o（即--optimize-autoloader）一起用：composer dump-autoload -o --apcu
怎么验证 APCu 缓存真正在工作
不能只看命令有没有报错，得亲手查缓存内容：
- 写个临时脚本，运行
var_dump(apcu_fetch('composer-autoload-psr4'));，返回非false才算成功 - 如果返回
false，先检查apcu.enabled=1和apcu.stat=0是否都满足 - 注意：APCu 的 CLI 实例和 Web 实例默认不共享缓存（除非启用
apc.shm_size并设置apc.enable_cli=1），所以 Web 请求里查不到 CLI 生成的键——调试时统一用 CLI 测 - 清缓存用
apcu_clear_cache('user')，不是composer clear-cache
常见误操作和后果
很多团队踩坑是因为把 APCu 加载器当成“全局加速开关”，其实它非常脆弱：
- 在
composer install后没再跑dump-autoload -o --apcu，缓存根本没生成 - 开发中频繁改类位置或命名空间，却忘了重新
dump-autoload -o --apcu，导致缓存键和实际文件不一致，类加载失败 - 误以为
--apcu能加速所有require，结果发现vendor/autoload.php本身加载慢，那跟 APCu 无关——那是 OPCache 或文件系统的事 - CI 环境里 PHP 没装 APCu 扩展，但构建脚本仍执行
--apcu，命令不报错却无效果，上线后才发现没提速
APCu 自动加载缓存的关键不在命令多难敲，而在于 CLI PHP 配置、扩展状态、执行时机三者严丝合缝；漏掉任意一个，就只是白跑一条命令，连日志都不会提醒你。
