APCu autoloader 是否生效需三步验证：扩展已载入、CLI 模式启用、缓存已写入；--apcu-autoloader 仅在 install/update 且配合 -o 时生效，与 --apcu 作用不同；类找不到多因缓存未清或配置不一致。
APCu autoloader 真的生效了吗？先看这三行命令
没验证就以为开成功了，是线上缓存失效却查不出原因的最常见起点。APCu autoloader 不报错、不警告，静默降级为普通文件加载——你跑 composer install --apcu-autoloader 成功了，不代表它在用 APCu。
- 确认扩展已载入：
php -m | grep apcu（必须输出apcu） - 确认 CLI 模式可用：
php -r "var_dump(apcu_enabled());"（必须输出bool(true)；若为false，大概率是apc.enable_cli=0） - 确认缓存已写入：
php -r "var_dump(apcu_fetch('composer.loaded'));"（首次请求后应返回非空数组；若为bool(false)，说明未命中或未写入）
--apcu-autoloader 和 --apcu 有什么区别？别混着用
这两个参数名字像、作用近，但触发时机和依赖条件完全不同，混用会导致白配置。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
--apcu-autoloader：只在composer install或composer update时有效，生成带apcu_fetch()/apcu_store()的autoload_static.php；必须配合--optimize-autoloader（即-o）才真正起效 -
--apcu：仅对composer dump-autoload有效，且只影响autoload_classmap.php和autoload_psr4.php文件末尾追加存储逻辑；它不改autoload_static.php，也不参与主流 autoload 流程 - 错误示例：
composer install --apcu→ 无效参数，被忽略；composer dump-autoload --apcu-autoloader→ 报错“Unknown option”
为什么类找不到？90% 是缓存没清或配置没对齐
部署后出现 Class not found，不是代码问题，而是 APCu 缓存与 vendor 目录状态不一致。它不感知文件变更，只认 key。
- 每次修改
composer.json中的autoload段（如增删 PSR-4 前缀），都必须重新生成 APCu 缓存：composer dump-autoload -o --apcu-autoloader或重装：rm -rf vendor && composer install -o --apcu-autoloader - 生产部署脚本里务必加清理步骤：
php -r "apcu_clear_cache('user');"（否则旧映射残留，新类永远查不到） - 关键配置必须同步：Web SAPI 和 CLI 的
php.ini是两套，用php -i | grep 'Loaded Configuration File'分别确认apcu.enabled=1和apcu.stat=0都已设好
性能提升不明显？检查这几个隐藏瓶颈
开了 --apcu-autoloader 却测不出速度变化，往往是因为它根本没跑在关键路径上，或者被更高层机制覆盖了。
- APCu 只缓存“类名 → 文件路径”的映射，不缓存文件内容；真正卡顿常来自
realpath()或 OPcache 未启用——先确保opcache.enable=1且opcache.validate_timestamps=0 - APCu 是进程级缓存，PHP-FPM 多 worker 下冷启动请求仍走慢路径；观察
apcu_cache_info()['num_hits'] / ['num_misses']，命中率低于 80% 就要查内存是否够（apc.shm_size至少 64M） - 不要在开发环境开它：
apcu.stat=1（默认）会让每次 require 都检查文件时间戳，直接废掉所有收益；本地请关掉，只在 CI/CD 或部署脚本中启用
