先定位卡点：用composer dump-autoload -vvv查看最后成功扫描的文件路径；再隔离排查——临时重命名可疑目录（如tests/、legacy/）；最后在composer.json中通过exclude-from-classmap显式排除.bak/.swp/含BOM等非法PHP文件。
dump-autoload 扫描卡住或报 ParseError 怎么办？
Composer 在扫描 PHP 文件时遇到语法错误、BOM 头、临时文件（如 .php.swp、config.example.php）会直接中断，并抛出类似 PHP Parse error: syntax error, unexpected '' 的错误，而不是跳过。这不是配置问题，是它真的读到了非法内容。
- 用
composer dump-autoload -vvv查看最后成功加载的文件路径，定位卡点 - 临时重命名可疑目录（比如
tests/、legacy/或helpers/），再试一次快速隔离 - 在
composer.json中加"exclude-from-classmap"显式排除干扰项："exclude-from-classmap": ["src/Config/example.php", "src/Helpers/old_*.php"]
- 避免在 autoload 路径下放任何带
.php后缀但不含<?php的文件（如模板、配置示例、Markdown 片段）
执行完 dump-autoload 还是 Class not found？先盯这三处
命令跑成功 ≠ 类进了映射表。常见“假成功”是因为 autoload 配置本身没覆盖到你的类路径，或者路径/命名空间不匹配。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer.json的"psr-4"里声明的路径是否真包含该类？比如配了"App\": "app/"，那App\Http\Controllers\HomeController就必须在app/Http/Controllers/HomeController.php - 检查类文件名是否与类名完全一致（大小写敏感）：Linux/macOS 下
homecontroller.php≠HomeController.php - 运行
composer show --path your/package-name确认包是否真被 autoload 映射收录；如果是自己写的类，用composer dump-autoload -v看扫描日志里有没有扫到你那个目录
vendor/autoload.php 引入失败导致全盘失效
很多“Class not found”根本不是 Composer 映射问题，而是入口脚本压根没加载自动加载器——这是最常被忽略的底层前提。
- 确认入口文件（如
index.php、CLI 脚本）第一行无输出前就写了：require __DIR__ . '/vendor/autoload.php';
- 别用
../vendor/autoload.php这类相对路径，__DIR__才可靠；Web 环境注意$_SERVER['DOCUMENT_ROOT']和脚本实际位置可能不一致 - 加一行
var_dump(file_exists(__DIR__ . '/vendor/autoload.php'));手动验证路径是否存在，尤其在 Docker 或部署后路径易变
OPcache、IDE 缓存和 --no-dev 导致“明明 reload 了却还是旧错”
命令行跑通但 Web 请求仍报错？大概率是缓存没清干净，或者环境参数不一致。
- CLI 和 Web SAPI 的 OPcache 是分开的：
php -r "opcache_reset();"只清 CLI；Apache/Nginx 需要重启服务，或调用对应 SAPI 的 reset 页面 - CI/CD 中如果用了
composer install --no-dev，而测试类写在autoload-dev里，这些类路径根本不会进生成的 autoload 文件 —— 要么删掉--no-dev，要么加--dev参数跑dump-autoload - 某些 IDE（如 PHPStorm）会缓存类索引，改完 composer.json 后手动触发 “Reload project from composer.json” 或清缓存
