Composer依赖分析失效的根本原因是项目结构错位：composer.json必须在根目录，vendor/不能嵌套，PSR-4映射需严格对齐文件路径、命名空间与autoload配置，否则所有优化命令均无效。
Composer 依赖分析不能只信工具，项目结构错位会让所有优化失效。 你跑 composer-unused 报“XX 包未使用”，上线后却抛 Class not found；你加了 "optimize-autoloader": true，但类加载速度纹丝不动——问题大概率出在项目结构本身，而非配置或命令。
composer.json 必须在根目录，且 vendor/ 不能嵌套
这是所有依赖分析和自动加载的前提。Composer 只读取当前工作目录下的 composer.json，不会向上找父目录，也不会向下进子目录。如果你把 composer.json 放进 src/ 或 app/，执行 composer install 会生成错误的 vendor/ 路径，导致自动加载器找不到任何类。
- 应用项目：根目录下应有
composer.json、public/（Web 入口）、src/、vendor/，三者同级 - 库项目：根目录下只有
composer.json、src/、tests/，绝不能有vendor/—— 库不安装依赖，由使用者安装 -
vendor/必须被.gitignore排除，但composer.lock必须提交 —— 它是生产环境一致性的唯一依据
autoload 配置必须与文件系统、命名空间三者对齐
PSR-4 映射不是“写对格式就行”，而是路径、命名空间声明、文件位置必须严丝合缝。常见错误是改了目录名但忘了同步改 composer.json 里的 "psr-4" 值，或者类文件里写的 namespace 和映射前缀不一致。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 例如：类文件在
src/Http/Controllers/HomeController.php，内容为namespace AppHttpControllers;，那composer.json就得配："autoload": { "psr-4": { "App\": "src/" } } -
src/下不能混放不同命名空间的类，比如同时放App和Vendor开头的类，自动加载器会误判或漏加载 - 开发时用
composer dump-autoload -o生成优化映射，但上线前要确认它没漏掉反射类、动态注册类等非常规加载点
composer-unused 识别“无用库”不可靠，必须人工交叉验证
composer-unused 是静态扫描工具，它查 use、new、class_exists 这些字面量，但 PHP 的动态特性让它天然漏报：
- 反射调用：
new ReflectionClass('Some' . $suffix)不会被识别 - 服务容器绑定、Laravel 的 Service Provider、Symfony Bundle 都不写
new，全靠配置驱动，composer-unused视而不见 - 测试代码默认不扫描，但有些包（如
phpunit/phpunit）只在tests/里用，会被误判为“无用” - 更稳妥的做法是：
grep -r "Vendor\Package" src/ app/ --include="*.php"，再结合composer depends vendor/package-name看是否被其他包间接依赖
生产环境的 autoload 优化必须配合结构才生效
光加 "optimize-autoloader": true 和 "classmap-authoritative": true 没用，如果 src/ 目录下存在大量空目录、无效文件，或 PSR-4 映射覆盖了不该覆盖的路径，生成的 autoload_classmap.php 会臃肿且不准。
- 先确保
autoload配置精准（比如只映射"App\": "src/"，而不是"\": "src/"） - 运行
composer dump-autoload --optimize --classmap-authoritative，检查生成的vendor/composer/autoload_classmap.php是否只含真实存在的类 - 线上部署必须加
--no-dev，否则phpunit、symfony/debug-bundle这类 dev-only 包会混入 autoload 表，既占内存又可能引发冲突 - APCu 缓存需额外启用：
"apcu-autoloader": true，但前提是 PHP 已装并启用了apcu扩展
最常被忽略的一点：所有优化都建立在 composer.lock 文件完整、未被手动编辑、且与当前源兼容的基础上。一旦 lock 文件损坏或指向已下线的私有源，composer install 会退化成全量解析，前面所有结构和配置努力都会被卡在 Resolving dependencies 里动弹不得。
