APCu 仅在启用 classmap 或优化自动加载器（composer dump-autoload -o）且配置 apc.enable_cli=1 时生效；需扩展加载、CLI 模式启用、配合 --apcu 参数生成缓存文件，并验证 apcu_fetch 命中率。
APCu 能显著提升 Composer 自动加载性能，但仅当项目使用 classmap 或 psr-4 + 生成的优化自动加载器（composer dump-autoload -o）时才生效；直接用 require 引入未优化的 autoload.php 不会走 APCu 缓存。
启用 APCu 前必须确认扩展已加载且配置正确
APCu 不是开箱即用的——它需要 PHP 扩展启用、共享内存可用、且 Composer 明确开启支持。常见错误是只装了扩展却没配 apc.enable_cli=1，导致命令行下（如 composer install）完全不生效。
-
php -m | grep apcu确认扩展已加载 - 检查
php.ini中：extension=apcu.so apc.enabled=1 apc.enable_cli=1 apc.shm_size=64M
- CLI 模式下必须设
apc.enable_cli=1，否则composer dump-autoload -o无法写入缓存 - 若用 Docker，确保容器内
php.ini和 CLI 配置一致（php -i | grep apc查实际生效项）
使用 composer dump-autoload -o --apcu 生成 APCu 兼容自动加载器
这个命令会生成两套文件：vendor/autoload.php（入口）和 vendor/composer/autoload_classmap.php（类名→路径映射），后者会被 APCu 缓存。注意：APCu 加速只对 classmap 方式有效，PSR-4 的动态查找逻辑本身不进 APCu。
-
-o（optimize）是前提：它把所有 PSR-4/PSR-0 映射提前解析为静态classmap数组 -
--apcu是开关：告诉 Composer 在生成的autoload_static.php中插入apcu_fetch()/apcu_store()调用 - 执行后检查
vendor/composer/autoload_static.php是否含apcu_fetch('composer.loaded')—— 没有说明未生效 - 若提示
APCu is not enabled，不是扩展没装，而是 CLI 下apc.enable_cli为 0 或被覆盖
验证 APCu 缓存是否真实命中
光看命令成功不代表运行时就加速了。PHP 请求中需触发 apcu_fetch() 成功返回，才算真正走缓存路径。最容易忽略的是：APCu 的 key 是带 Composer 安装路径哈希的，换目录或改 composer.json 后旧缓存自动失效，但不会报错。
立即学习“PHP免费学习笔记（深入）”；
- 在项目中加临时调试代码：
<?php var_dump(apcu_exists('composer.autoload.' . substr(md5(__DIR__), 0, 8))); ?> - 用
apcu-bc或apcu-panelWeb 界面查看 key 存在性与 hit rate - 对比开启前后
microtime(true)记录require 'vendor/autoload.php'耗时（建议压测 100+ 次取均值） - 注意：APCu 缓存的是类名→文件路径映射，不是文件内容。类文件变更后需重新
dump-autoload，否则加载旧路径
APCu 加速效果高度依赖 classmap 的完整性——如果项目里混用 files 类型自动加载（比如全局函数），这部分不会进 APCu；另外，某些 SaaS 多租户环境禁用 APCu（因共享内存跨账户不安全），这时强行启用反而引发不可预知的类加载失败。
