composer启用apcu自动加载器需满足：php加载apcu扩展且apcu.enabled=1、apcu.stat=0；执行composer dump-autoload –apcu（非install），并开启”optimize-autoloader”: true；验证需用apcu_fetch检查缓存键。
composer install 时没走 APCu 缓存？检查 apcu.enabled 和 apcu.stat
APCu 缓存对 Composer 自动加载器提速有效，但前提是 PHP 确实加载了 APCu 扩展且配置允许写入。常见现象是运行 composer install 或 composer dump-autoload 后，apcu_fetch() 返回 false，缓存始终未命中。
- 确认
extension=apcu.so（linux/macos）或extension=php_apcu.dll（windows）已写入php.ini，且php -m | grep apcu能看到输出 -
apcu.enabled=1必须为1（不是On），否则扩展不生效 -
apcu.stat=0是关键：设为1时 APCu 会每次检查文件修改时间，导致自动加载器跳过缓存；生产环境务必关掉 - PHP CLI 和 Web SAPI 的
php.ini可能不同，用php -i | grep 'Loaded Configuration File'确认 CLI 实际加载的配置
启用 composer apcu-autoloader 的正确命令和时机
Composer 不会在默认安装流程中自动启用 APCu 加载器，必须显式触发，且只对 autoload_classmap.php 和 autoload_psr4.php 生效——它不加速 require 或 include，只加速类名到文件路径的映射查找。
- 执行
composer dump-autoload --apcu，而非composer install --apcu（后者无效） - 该命令生成
vendor/composer/autoload_classmap.php等文件的同时，会在末尾追加 APCu 存储逻辑，依赖apcu_store() - 仅当
composer.json中"optimize-autoloader": true开启时，--apcu才真正起作用；否则生成的映射文件太稀疏，缓存收益极低 - 每次修改
composer.json或运行composer update后，必须重新执行composer dump-autoload --apcu
APCu autoloader 在哪些场景下反而变慢？
APCu 缓存不是银弹。在小项目、CI 环境或频繁重装依赖的场景下，它可能增加开销而非提速。
- 容器化部署（如 docker）中，每次构建都重装 vendor，APCu 缓存无法跨进程复用，
apcu_store()白费一次序列化+写入 - 开发环境开启
xdebug时，APCu 的键名生成和校验逻辑会被显著拖慢，实测比原生 autoload 慢 10%~20% - 类数量少于 500 个时，PHP 数组查找已足够快，APCu 的哈希计算+共享内存访问反而成瓶颈
-
opcache.enable_cli=1开启后，CLI 下的类加载本身已被优化，APCu 加速边际效应大幅下降
验证 APCu autoloader 是否真正在工作
不能只看命令是否成功，得查缓存是否被写入、读取、命中。最直接的方式是用 PHP 脚本探测，而不是依赖 composer 输出。
- 运行
php -r "var_dump(apcu_fetch('composer-autoload-'.md5(__DIR__.'/vendor/autoload.php')));"，有非false输出才说明缓存存在 - 在项目入口前插入
apcu_clear_cache();，再请求页面，观察首次加载是否明显变慢（说明之前确实在用缓存） - 注意键名中的
md5是基于vendor/autoload.php文件内容计算的，只要该文件变化（比如dump-autoload重写），旧缓存就失效 - APCu 的
apc.serializer配置影响性能：默认php序列化较慢，若 PHP ≥ 7.4 可设为igbinary（需额外扩展），但多数项目没必要
APCu autoloader 的实际效果高度依赖部署方式和项目规模，本地开发几乎感受不到差异，而高并发 CLI 任务（如队列 worker）里，缓存键冲突、内存碎片、apcu.ttl 设置不当都可能导致偶发性类找不到——这些细节比“怎么开”更值得盯紧。