--apcu-autoloader 无效的主因是环境不匹配：仅在 PHP-FPM 或 mod_php 下生效，CLI 模式因进程不复用而失效；需 APCu 启用、composer≥2.2、启用 optimize-autoloader 且避免混用命令。
为什么 --apcu-autoloader 有时没效果？
APCu 自动加载器不是“开了就快”，它依赖两个硬性前提：PHP 进程必须复用（如 PHP-FPM 模式），且 APCu 扩展已启用并允许用户缓存。CLI 下直接 php composer install --apcu-autoloader 基本无效——因为 CLI 每次启动都是新进程，APCu 缓存无法跨请求保留。
常见错误现象：Class not found 或安装后无性能提升，多半是环境不匹配。
- 确认 APCu 已启用：
php -m | grep apcu，且apc.enable_cli=0（CLI 下应为 0，FPM 下为 1） - 仅在 PHP-FPM 或 Apache mod_php 环境中启用才真正生效
- Composer 版本需 ≥ 2.2，旧版不支持该参数
composer install 和 composer dump-autoload 的区别
--apcu-autoloader 只在生成自动加载文件时起作用，不是运行时开关。它会把类映射写入 APCu，跳过文件系统查找，但前提是后续请求由同一个 PHP 进程（或共享 APCu 的进程池）处理。
所以关键操作是：
- 部署时用：
composer install --apcu-autoloader --no-dev（生产环境推荐） - 开发中改了类名或命名空间后，需重新生成：
composer dump-autoload --apcu-autoloader - 不要混用：
composer install --apcu-autoloader+composer dump-autoload（无参）会导致 APCu 缓存被覆盖为普通文件缓存
APCu 缓存失效的几个隐藏触发点
即使启用了，缓存也可能被意外清空或绕过。最常被忽略的是 Composer 的 classmap-authoritative 配置和 APCu 的内存限制。
- 若
"optimize-autoloader": true未启用，--apcu-autoloader会被忽略 - APCu 内存不足时（
apc.shm_size太小），新类映射写不进去，降级回文件查找 - 修改
composer.json后未重装，旧 APCu 缓存仍存在但映射已过期，导致类找不到 - 使用
composer update时默认不带--apcu-autoloader，必须显式加上
怎么验证 APCu 缓存真正在工作？
不能只看命令是否成功执行，得查运行时行为。最直接的方法是观察 opcache_get_status()['opcache_statistics']['opcache_hit_rate'] 无意义——APCu 是独立缓存，得查它自己。
- 在 PHP-FPM 请求中调用：
apcu_cache_info('user')，检查num_hits是否随请求增长 - 临时加日志：在自动加载逻辑前插入
var_dump(apcu_exists('ComposerAutoloadNspMap')); - 用
apcu_clear_cache('user')手动清空后对比首屏加载时间，差异明显说明生效
复杂点在于：APCu 缓存是 per-process 的，FPM 子进程重启、配置 reload、甚至某些监控脚本调用 apcu_clear_cache() 都会让缓存归零——别只盯着 Composer 命令本身。
