根本原因是自动加载映射未更新或依赖版本未正确安装；需运行 composer dump-autoload -o、检查 autoload_classmap.php、确认实际安装版本及 autoload 配置。
为什么 composer install 后某个类突然找不到
根本原因通常是自动加载映射没更新，或依赖版本实际没装对。Composer 不会自动重刷 vendor/autoload.php 的类映射，尤其在切换分支、手动删过 vendor/ 或用 --no-autoloader 时容易中招。
- 先跑
composer dump-autoload -o强制重建优化版自动加载文件（别只信缓存） - 检查
vendor/composer/autoload_classmap.php里有没有你调用的类名——没有就说明该包根本没被正确安装或其autoload配置有误 - 运行
composer show vendor/package-name确认实际安装的版本号，别只看composer.json里的约束 - 如果用了
path类型仓库，确认对应本地路径下composer.json的autoload字段是否生效（比如漏了psr-4命名空间映射）
升级后 Call to undefined method 怎么快速定位是哪个包改了 API
这不是 PHP 报错层级的问题，而是语义化版本失控的典型表现：某个依赖在次版本（如 2.3.0 → 2.4.0）里删了方法，但没升主版本，而你的代码还直调它。
- 用
composer show --tree vendor/project查当前依赖树，重点看报错方法所属类的上游包版本 - 对比升级前后
composer.lock文件，搜索报错类名所在的包，看version和source的reference是否变了（Git commit hash 变了就说明代码真不一样了） - 进对应包的 GitHub Release 页面，查 CHANGELOG 或直接 diff 两个 tag 的源码（比如
git diff v2.3.0...v2.4.0 src/SomeClass.php） - 临时加一句
var_dump(method_exists(SomeClass::class, 'brokenMethod'));确认是不是运行时才消失，排除 autoloader 缓存干扰
composer update 跳过某些包却仍影响功能，怎么揪出隐式依赖
你以为锁定了 "monolog/monolog": "2.9.1" 就安全？错。其他包可能在 require-dev 或间接依赖里带入更高版 Monolog，Composer 默认会统一收束到一个兼容版本，从而覆盖你的显式锁定。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
composer depends monolog/monolog查谁在拉这个包（包括 dev-only 依赖） - 加
-t参数看完整依赖链：composer depends -t monolog/monolog，重点关注非 root 包的 require 行为 - 如果发现某个测试工具（如
phpunit/phpunit）悄悄带了monolog，而你又没在require-dev显式锁它，就得补上："phpunit/phpunit": "9.6.13 as 9.6.0"这种 alias 锁定 - 检查
composer.json里有没有"minimum-stability": "dev"或"prefer-stable": false，它们会让 Composer 主动选不稳定版本来满足依赖
CI 环境和本地行为不一致，composer install 结果不同怎么办
差异几乎都来自 composer.lock 没提交、PHP 版本不匹配、或平台配置被忽略。Composer 会根据当前环境动态调整可安装版本范围。
- 确认 CI 和本地都用了完全相同的 PHP 版本（
php -v），特别是 8.0+ 对联合类型、构造器属性提升的支持差异会直接导致某些包无法安装 - 检查
composer.json里有没有"platform"配置，比如"ext-gd": "8.1.0"—— 如果 CI 没装 GD 扩展但 lock 文件里记了它，就会跳过需 GD 的包 - 运行
composer install --dry-run在 CI 上预演，看它打算装哪些版本；再对比本地composer show --installed输出 - 最硬核但有效：CI 中加一步
composer update --lock并把新生成的composer.lock提交，强制同步（前提是团队接受 lock 文件频繁变更）
依赖问题最难缠的从来不是报错本身，而是错误发生在哪一层：是自动加载失效、API 被删、版本被顶替，还是环境变量悄悄改了平台能力。每次遇到先盯死 composer.lock 和 vendor/composer/ 下的真实映射，比猜更快。
