--apcu-autoloader必须与--optimize-autoloader同时使用，因为APCu缓存依赖优化后生成的完整classmap映射表（autoload_classmap.php），否则运行时仍需遍历PSR-4目录，导致缓存无效。

APCu autoloader 不是靠改 php.ini 或写代码启用的，必须在 Composer 构建阶段显式触发，且只对生产环境有效——本地开反而容易类找不到。

为什么 --apcu-autoloader 必须搭配 --optimize-autoloader

APCu 缓存的是“类名 → 文件路径”的映射表，而这个映射表只有在 --optimize-autoloader（即生成 autoload_classmap.php）时才完整、可序列化。不加这个参数，Composer 仍依赖运行时遍历 PSR-4 目录，APCu 拿不到稳定结构，缓存无效。

• composer install --apcu-autoloader --optimize-autoloader --no-dev 是最简安全组合
• 单独跑 composer dump-autoload --apcu 也行，但前提是之前已执行过 --optimize-autoloader（或配置了 "optimize-autoloader": true）
• 如果项目用了 "classmap-authoritative": true，APCu 缓存会更紧凑，但要注意：Laravel 的某些 Service Provider 动态注册类可能失效

APCu 扩展没生效的三个典型表现

缓存根本没写进去，php -r "var_dump(apcu_fetch('composer:autoload'));" 返回 false，常见原因：

Discussion Composer

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

下载

• apc.enabled=0 或 extension=apcu.so 没加载（FPM 和 CLI 的 php.ini 可能不同，用 phpinfo() 或 php -m | grep apcu 分别确认）
• Docker 环境里 apc.enable_cli=0（默认值），FPM 进程无法访问 APCu；需在 FPM 的 www.conf 或 env 中显式设为 1
• opcache.file_cache 开启时，PHP 可能绕过 APCu 用户缓存——关掉它或确保 opcache.enable_file_override=0

部署后类找不到？不是 bug，是缓存没清

APCu 缓存不会自动感知 vendor/ 更新，旧映射还在内存里，新类路径查不到。这不是 Composer 问题，是运维动作缺失：

• 每次 composer install 或 dump-autoload 后，必须清 APCu：用 apcu_clear_cache('user') 或脚本中加 php -r "apcu_clear_cache('user');"
• 不能只清 composer:autoload 键——APCu 的 user cache 是扁平命名空间，清整个 user 区最稳妥
• 若用 systemd 或 supervisord 管理 PHP-FPM，记得 reload 前清缓存，否则第一个请求会写旧映射

真正难调的点不在命令怎么写，而在 APCu 的生命周期和部署流程是否闭环——缓存写进去了，但没人告诉它该什么时候失效。