报错末尾信息直接定位问题层级：permission denied类属权限问题，ext-xxx或php版本问题属cli环境配置，no composer.lock属git分支状态，需依次验证路径归属、扩展启用、lock文件存在性及镜像配置。
先看报错末尾那行字，不是“Loading composer repositories”卡住，就是具体错误信息——它直接告诉你问题在哪一层。
报错含 Permission denied 或写入失败
这不是网络或 PHP 版本问题，是当前用户没权限往目标路径写文件。Composer 报错里带的路径就是线索，比如：file_put_contents(/home/user/project/vendor/autoload.php): Permission denied → 问题在 vendor/；Could not write to /home/user/project/composer.lock → 修 composer.lock；Writing cache file ~/.composer/cache/... → 查全局缓存目录。
- 立刻执行这三行查归属：
ls -ld vendor/、ls -ld composer.lock、ls -ld $(composer config --global cache-dir) - 只要任意一行第三列（属主）不是你的用户名（
$(whoami)），就说明所有权错配 - 修复命令用
sudo chown -R $USER:$USER vendor/ composer.lock（注意末尾不加/，否则composer.lock文件本身可能漏掉） - 禁用
chmod -R 777：它不解决根本问题，还会让 CI 拒绝提交、Git 提示 ownership changed、后续dump-autoload静默失败
报错含 ext-xxx 或 requires php
Composer 走的是 CLI 模式，只认 php -m 和 php --ini 的输出，和浏览器里看到的 phpinfo() 完全无关。报错末尾的 ext-redis 或 php ^8.1 就是你要查的目标。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
php -m | grep redis（把redis换成报错里的扩展名），不在列表里就是真缺 - 若在列表里，再跑
php --ini，盯住Loaded Configuration File:那行路径，打开对应php.ini，确认extension=redis.so存在且未被注释 - Ubuntu/Debian 下装完扩展后必须执行
sudo phpenmod redis才真正启用；macOS + Homebrew 要改/opt/homebrew/etc/php/8.2/php.ini并重启终端 - PHP 版本不匹配时，别乱加
--ignore-platform-reqs，优先用/usr/bin/php8.1 composer install指定解释器，更安全
报错含 No composer.lock file present 或 Your lock file does not contain a compatible set of packages
前者说明你 checkout 的分支根本没提交 composer.lock，或者它被 .gitignore 错误排除了；后者通常是 Git 合并时手动改过 composer.lock，或两个分支各自运行过 composer update 并提交了不同版本。
- 先在当前分支下运行
ls -l composer.lock，不存在就别硬跑composer install—— 新版 Composer 会直接报Command "install" is not defined - 若存在但校验失败，用
git checkout --ours composer.lock恢复主干版本，再删vendor/，然后重跑composer install - 如果只是想让
composer.lock对齐当前composer.json（比如你刚加了依赖但没更新 lock），用composer update --lock，它只重写 lock，不碰 vendor - CI/CD 环境下常见漏点：
vendor/被误加进.gitignore，导致拉不到完整代码树；composer.json里包名末尾多空格，install 不报错但 autoload 映射失效
报错含 Could not find package 或 file could not be downloaded
先验证包是否真实存在：https://packagist.org/packages/vendor/name 能打开，composer search vendor/name 有结果，再排查镜像配置。国内镜像不是万能的，同步延迟、URL 格式错误、缓存残留都会导致 404。
- 检查镜像配置是否正确：
composer config -g repo.packagist必须输出 JSON 对象，且 URL 是 HTTPS、结尾带/、type 值为composer - 切镜像后必须清缓存：
composer clear-cache；Windows 还要手动删%LOCALAPPDATA%\Composer\cache - 删掉
vendor/和composer.lock：后者硬编码了旧源地址，不清它就会反复重试失败路径 - 私有包报 404？重点查
repositories配置是否漏type或url，GitHub 私库需auth.json且 URL 不能带@username；分支名必须真实存在（dev-main要求远程有main分支）
最常被忽略的点是：你以为在修 Composer，其实是在修 PHP CLI 环境、文件系统归属、或 Git 分支状态。报错信息里的路径、扩展名、包名、PHP 版本，每一个都是可验证的原子事实，别跳步，挨个对。
