Class not found但文件存在，主因是autoload未重建或未加-o参数：默认模式只更新PSR-4映射，不扫描文件生成classmap；新增、移动类或改命名空间必须加composer dump-autoload -o强制全量扫描并生成classmap。
Class not found 但类文件明明存在？不是代码写错了，大概率是 autoload 没重建，或者重建得不彻底。
为什么 composer dump-autoload 有时没用
默认不扫描文件，只更新 PSR-4 路径映射配置。比如你新增了 App\Services\PaymentService，但 vendor/composer/autoload_classmap.php 里压根没这行，class_exists() 就会返回 false——因为 classmap 是空的。
- 不加参数：只重写
autoload_psr4.php，不碰autoload_classmap.php - 加
-o（即--optimize）：清空并全量扫描所有autoload配置目录下的.php文件，生成新 classmap - 改了命名空间、移动了文件、新增了类 → 必须加
-o，否则等于没做
什么时候必须加 -o 参数
遇到这些情况，不加 -o 就别指望 autoload 能认出新类：
-
Class "AppServicesPaymentService" not found，但文件在src/Services/PaymentService.php且命名空间正确 - 把
src/Models/User.php移到src/Domain/User.php，也同步改了composer.json的 PSR-4 映射 - CI 流水线中先执行
composer install --no-dev，之后又合入了tests/或src/Helpers/下的新工具类
验证是否生效最直接：运行 php -r "require 'vendor/autoload.php'; var_dump(class_exists('App\Services\PaymentService'));" —— 返回 bool(true) 才算成功。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
离线环境怎么安全重建 autoload
离线时 composer dump-autoload 可能卡住或报错，是因为它默认会尝试加载插件、校验包完整性。要确保真离线运行，必须加两个参数：
-
--no-plugins：禁用所有插件（比如加速下载的hirak/prestissimo），避免偷偷联网 -
--optimize（或-o）：强制扫描本地文件，生成 classmap，不依赖动态查找
前提是：vendor/ 存在且完整、composer.lock 和 composer.json 一致、目标 autoload 目录（如 src/）有读取权限且非空。否则会静默跳过，不报错也不警告。
生产部署后 Class 还找不到？别只盯 Composer
即使 composer dump-autoload -o --classmap-authoritative 成功运行，vendor/autoload.php 时间戳也更新了，仍报 Class not found，大概率是 PHP 的 opcode 缓存没清：
- OPcache 缓存了旧的
autoload_classmap.php字节码，PHP 实际在用“上一版”映射 - 执行
php -r "opcache_reset();"（需opcache.enable=1且opcache.revalidate_freq=0） - Apache + mod_php 下重启 Apache 不一定清掉 OPcache，必须显式调用
opcache_reset()
最容易被忽略的是：classmap 里确实有那个类，但类文件里写的命名空间和实际路径不匹配（比如 namespace App\Services; 却放在 src/Helpers/ 下），Composer 不校验这个，只管映射路径——结果就是“能找到文件，但类名对不上”，照样 Class not found。
