Composer报错找不到包通常源于配置、网络或缓存问题，应按顺序排查：包名与版本规范性、镜像源有效性、缓存完整性、项目级仓库配置。
Composer 报错找不到包，绝大多数情况不是包真不存在，而是本地配置、网络或缓存层面出了偏差——先别急着改 composer.json，按顺序排查这四类问题更高效。
检查包名拼写和版本约束是否符合 Packagist 规范
Composer 只认 Packagist.org 上注册的包名（如 monolog/monolog），不支持 GitHub 仓库直写（如 github.com/Seldaek/monolog）；版本号也必须是语义化格式或合法别名（^2.0、dev-main、1.x-dev），不能写 latest 或 master。
- 用浏览器打开
https://packagist.org/packages/{vendor}/{package}确认包是否存在且未被弃用 - 运行
composer search {keyword}查找近似包名，避免大小写或连字符错误（laravel/framework≠Laravel/Framework） - 若想安装开发分支，确保
minimum-stability允许对应稳定性（如dev-main需设为"minimum-stability": "dev"或加"prefer-stable": true并显式指定分支）
确认是否因镜像源失效或协议变更导致拉取失败
国内用户常用阿里、腾讯等镜像源，但它们同步有延迟，且部分镜像已停止维护（如华为云镜像已于 2023 年下线）；另外 Packagist 自 2022 年起强制 HTTPS，若本地配置了 HTTP 源会直接报 400 错误。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 执行
composer config -g repo.packagist查看当前全局源，若返回{"url": "http://packagist.phpcomposer.com", "type": "composer"}这类已失效地址，立刻删掉：composer config -g --unset repos.packagist - 临时切回官方源验证：
composer config -g repo.packagist composer https://packagist.org - 国内推荐稳定源：
composer config -g repo.packagist composer https://packagist.phpcomposer.com（注意：该域名目前由阿里云代理，实际可用）
清理 Composer 缓存并重试
Composer 会缓存 composer.json 解析结果、包元数据甚至 ZIP 包，一旦缓存损坏（尤其在断网重试后），会导致“包存在但死活装不上”的假象。
- 清除全部缓存：
composer clear-cache（比rm -rf ~/.composer/cache更安全） - 若仍失败，可加
-vvv参数运行安装命令，观察最后几行是否卡在Downloading https://packagist.org/p2/xxx.json—— 这说明元数据请求失败，大概率是 DNS 或 TLS 问题 - 某些企业网络会拦截
.json后缀响应，此时需联系 IT 部门放行packagist.org的 JSON MIME 类型
检查项目级配置是否禁用了所需仓库类型
项目根目录下的 composer.json 若定义了 repositories，会完全覆盖 Packagist 默认行为；若其中包含 type package 或 path 类型仓库，且配置错误，Composer 就不再自动 fallback 到 Packagist。
- 运行
composer config repositories查看当前生效仓库列表 - 若输出中出现非
packagist类型仓库，检查其url字段是否可访问（如本地path仓库路径是否真实存在） - 临时禁用自定义仓库测试：
composer install --no-plugins --no-scripts --repository-url=https://packagist.org
真正棘手的情况往往是多个因素叠加：比如镜像源同步滞后 + 本地缓存损坏 + minimum-stability 设置过严。每次只改一个变量，用 composer require -vvv 观察日志里第一个失败点，比反复修改 composer.json 更省时间。
