答案：composer报“could not find package”主因是源未生效、缓存未清理或包名错误，而非包不存在；需用composer diagnose确认镜像地址、执行composer clear-cache并删除对应缓存目录、curl验证镜像同步状态，并严格核对包名大小写与vendor前缀。
composer install 报 “Could not find package” 是源没生效或缓存没清干净
不是包不存在，而是 Composer 当前实际请求的源里压根没有它。国内镜像（如阿里云）有 5–30 分钟同步延迟，新发布的包、dev-main 分支、刚打的 tag 都可能还没同步过去。
先确认你真正在用哪个源：composer diagnose，看 Repo packagist.org: 这一行后面跟的 URL 是否是你设的镜像地址（比如 https://mirrors.aliyun.com/composer/），且结尾有斜杠；如果还是 https://packagist.org/，说明配置被项目级 repositories 覆盖了，或者全局配置根本没写对。
- 执行
composer clear-cache（注意不是cache-clear，已废弃） - 删掉元数据缓存目录：
rm -rf ~/.composer/cache/repo/https---mirrors-aliyun-com-composer（路径按你实际镜像 URL 转义） - 用
curl -I https://mirrors.aliyun.com/composer/p/vendor/name.json直接测镜像是否已同步——HTTP 200 且Last-Modified接近当前时间才算同步完成
包名拼错或大小写不对，是最快踩到的坑
Composer 严格匹配 Packagist 上注册的完整包名：monolog/monolog 和 Monolog/Monolog 是两个不同包，后者直接 404。别从网页、聊天记录里复制包名——里面可能藏不可见空格或全角字符。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 打开
https://packagist.org/packages/vendor/name（把vendor/name换成你要装的完整包名），看是否返回有效页面 - 检查命令里有没有漏掉 vendor 前缀，比如把
laravel/sanctum写成sanctum - 确保 Git tag 是
v1.0.0或1.0.0，不能是release-1.0、v1.0_final这类非标准格式
私有包或 GitHub 仓库包报 404，大概率是 repositories 配错字段
Composer 默认只查 Packagist，你写了 myorg/my-private-package，但它既没上 Packagist，又没告诉 Composer “去我公司 GitLab 或本地文件夹里翻”，那它当然报 not found。
-
repositories必须包含完整type和url字段，例如：{"type":"vcs","url":"https://github.com/username/repo.git"} - Git 标签或分支名必须真实存在：
"dev-main"要求远程有main分支，"1.2.3"要求有对应 tag - GitHub 私有库需 token 认证：确保
auth.json里 token 有read:packages权限，且 URL 里不带@username（否则 Composer 会忽略认证）
require 命令加了 -w 反而找不到包？去掉重试
-w（即 --with-dependencies）会让 Composer 强制解析整个依赖树再合并约束，一旦某个已有包锁定了过老的子依赖版本，而你要装的新包要求更高版本，Composer 就可能放弃安装，报 “not found”——它其实是 “无法满足依赖”，但错误信息没说清楚。
- 去掉
-w重试：composer require vendor/name - 如果必须用
-w，先运行composer update --dry-run看冲突点在哪 - 旧版 Composer 对
-w处理更激进，建议升级到 2.x
composer.json 里写的包名、repositories 配置、或镜像元数据缓存三者之一出了偏差——每次出问题，优先跑 composer diagnose 和 curl -I 验证，比盲目换源快得多。
