apcu autoloader 不会自动启用，必须在 composer install 或 update 时显式添加 --apcu-autoloader 参数（且需配合 --optimize-autoloader），并确保 php cli 模式下 apc.enabled=1 和 apc.enable_cli=1 均生效，否则静默降级为文件加载。
APCu autoloader 不会自动启用，哪怕你装了扩展、跑了 composer install，只要没显式触发，它就完全不工作。
为什么 composer install 后 APCu 没生效？
根本原因不是 Composer 没“支持”，而是它压根没被要求启用。APCu autoloader 是一个可选开关，不是默认行为。
- 必须在
composer install或composer update时加--apcu-autoloader（注意是两个短横线），不能靠dump-autoload补救 -
composer dump-autoload命令根本不识别--apcu-autoloader，加了会报错：Unrecognized option - 如果已有
vendor/autoload.php，加参数也不会覆盖——得先删掉vendor/或用--no-scripts避免旧逻辑干扰 - 只对 Composer 自动生成的 autoload 逻辑生效（即
vendor/autoload.php加载路径），手动require的文件完全绕过
CLI 下报 “APCu is not enabled” 怎么办？
这个错误不是 PHP 扩展没装，而是 CLI 模式下 APCu 实际未启用。Web 环境（如 FPM）和 CLI 可能用不同 php.ini，配置互不影响。
- 运行
php -i | grep "Loaded Configuration File"查 CLI 实际加载的配置路径 - 确认该
php.ini中有extension=apcu.so（Linux/macOS）或extension=php_apcu.dll（Windows），且未被注释 - 必须设置
apc.enabled=1（值为数字1，不是On）和apc.enable_cli=1—— 后者常被忽略，但 CLI 下生成缓存必须开 - 某些 Docker 镜像或云环境默认关掉
apc.enable_cli，需手动补上；改完记得重启终端或用php -v验证无效，要用php -i
怎么验证 APCu autoloader 真正在跑？
别信命令没报错，得看生成的代码和运行时行为。
- 打开
vendor/autoload.php，搜索apcu_fetch或composer.autoload.—— 没这串字，说明根本没启用 - 在项目里加一行调试：
<?php var_dump(apcu_exists('composer.autoload.' . substr(md5(__DIR__), 0, 8))); ?>，返回true才算写入成功 - 检查
apcu.stat=0：设为1会让 APCu 每次检查文件修改时间，直接跳过缓存；生产环境务必关掉 - APCu 缓存键基于项目路径哈希，换目录、改
composer.jsonautoload 段后旧缓存自动失效，但不会报错，容易误判为“没生效”
APCu autoloader 到底加速哪一步？
它只缓存“类名 → 文件路径”的映射表（即 autoload_classmap.php 和 autoload_psr4.php 的解析结果），不碰文件内容，也不跳过 require_once。
- 适合依赖稳定、classmap 条目超 5000+ 的生产环境；小项目或开发期频繁改类，收益极低，还可能因缓存未清导致
Class not found - 与 OpCache 完全正交：OpCache 缓存 opcode，APCu 缓存映射表，二者可共存，但别混淆作用
- FPM worker 进程间共享缓存，CLI 每次执行是独立进程，所以 CLI 下测不到“加速效果”是正常的，别拿
php -r 'require...'测 - 部署后若类找不到，大概率是
vendor/更新了但 APCu 缓存没清，应在部署脚本中加：php -r "apcu_clear_cache('user');"
最常被跳过的点：APCu autoloader 必须和 --optimize-autoloader（或 -o）一起用才有效，单独加 --apcu-autoloader 会被静默忽略。
