apcu-autoloader 必须与 optimize-autoloader 同时启用，否则无效；它依赖 autoload_classmap.php 提供映射数据，且需 PHP 环境正确配置 APCu 扩展及参数，部署后需主动刷新缓存。

apcu-autoloader 必须和 optimize-autoloader 一起用

单独加 --apcu-autoloader 没效果，Composer 会静默忽略。它依赖优化后的类映射表（autoload_classmap.php）作为数据源，没这个基础，APCu 就没东西可缓存。

实操建议：

• 部署时统一用 composer install --optimize-autoloader --apcu-autoloader --no-dev
• 或在 composer.json 的 config 中写死：

  "optimize-autoloader": true,<br>"apcu-autoloader": true

• CI/CD 流水线里避免只跑 composer dump-autoload --apcu，它不重建 classmap，缓存内容可能过期

APCu 扩展本身得配对生效

常见现象是命令跑成功了，但监控发现 APCu 缓存命中率始终为 0——问题往往不在 Composer，而在 PHP 环境。

关键检查点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• extension=apcu.so 已加载（php -m | grep apcu）
• apc.enabled=1（注意不是 apc.enable_cli=1，那是 CLI 模式开关，FPM 下无效）
• apc.shm_size ≥ 32M（autoload_classmap.php 单文件就几 MB，太小会频繁驱逐）
• Docker 容器中确认 APCu 不是仅 CLI 模式：FPM 进程需能访问同一块共享内存，apc.enable_cli=0 是默认且正确的

缓存不更新？不是 bug，是预期行为

APCu 缓存不会自动感知 vendor/ 变更。部署新版本后出现 Class not found，大概率是旧映射还在 APCu 里挂着。

解决方式不是“清空所有 APCu”，而是精准失效：

• 每次部署后执行 composer dump-autoload --optimize --apcu（触发重写缓存）
• 或在部署脚本末尾加 php -r "apcu_clear_cache();"，强制刷新用户缓存区
• 别依赖 opcache_reset()，它不影响 APCu

classmap-authoritative 和 apcu-autoloader 能否共存？

可以，但要小心副作用。两者叠加确实能压到最低自动加载开销，但 classmap-authoritative 会让自动加载器彻底跳过 PSR-4 动态扫描——这意味着 Laravel 的某些运行时注册的 ServiceProvider、或依赖中用 spl_autoload_register 手动追加的类路径，会直接报错。

建议：

• 纯标准 PSR-4 项目（如 Symfony Console 应用）可放心开 classmap-authoritative + apcu-autoloader
• Laravel 项目优先只用 optimize-autoloader + apcu-autoloader，保留动态查找兜底能力
• 若硬要上 classmap-authoritative，务必配合 composer dump-autoload -a --no-dev 并在本地验证所有服务提供者是否正常加载

APCu 缓存层最易被忽略的一点：它只缓存“类名 → 文件路径”的映射，不缓存文件内容本身。所以即使开了 APCu，file_exists() 和 include 的 I/O 开销依然存在——真正省掉的是每次请求都要解析那几个 autoload_*.php 数组文件的过程。