直接原因是composer.lock记录的包版本或源信息与当前配置（私有仓库、镜像源等）不匹配，导致Composer无法定位下载地址；常见于误删lock文件、源切换未同步、认证失效或platform约束过滤。
vendor 清空后 composer install 报错“Package not found”
直接原因通常是 composer.lock 里记录的包版本或源信息，和当前配置（如私有仓库、认证、镜像源）不匹配。不是包真丢了，而是 Composer 找不到它该去哪下。
常见现象包括：
Could not find package xxx/yyy at version zzz-
Package xxx/yyy has a dependency on xxx/zzz which is not installed（其实是上游依赖没拉下来） - 本地有
composer.json，但composer install不读它，只认composer.lock，而 lock 文件可能残留了已下线的 snapshot 版本或内网地址
实操建议：
- 先确认是否误删了
composer.lock—— 如果没了，composer install会退化成composer update行为，可能升到不兼容版本，甚至因源不可达失败 - 运行
composer diagnose，它会检查网络连通性、认证配置、repositories是否有效，比如私有 packagist 的 token 过期或域名解析失败 - 用
composer show -p看当前已配置的包源（package repositories），确认你依赖的包是否在列表里；如果用了composer config repositories.xxx自定义源，检查 URL 和 type（vcs/composer/package）是否仍可用
私有包 404 或认证失败时怎么定位
私有包报 404 或 401 Unauthorized，往往不是 vendor 清理导致的，而是清理后重装暴露出原本被缓存掩盖的问题。
关键点：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- Composer 默认不会把私有源凭证存在
auth.json以外的地方，清空 vendor 不影响它——但如果你用的是环境变量（如COMPOSER_AUTH）或 CI 环境里没配好，install就会失败 - 检查
auth.json路径：项目根目录的auth.json优先级高于全局~/.composer/auth.json；若两者冲突，后者可能被忽略 - 对 Git 类私有包（type:
vcs），运行composer install -vvv，看日志里实际执行的git clone命令是否带了正确用户名（如https://token:x-oauth-basic@github.com/xxx/yyy.git）；若没带，说明认证没生效 - GitHub/GitLab 私有仓库推荐用 personal access token（PAT）而非密码，且 token 必须带
read:packages（GitHub）或api（GitLab）权限
composer update 和 composer install 混用引发的依赖错乱
很多人清完 vendor 后下意识跑 composer update，结果发现某些包版本跳变了，甚至引入了 BC break。这不是 bug，是预期行为：update 会忽略 composer.lock 的约束，重新解析依赖树。
真正安全的做法是：
- 只要
composer.lock还在，就只用composer install—— 它严格按 lock 文件还原，不查最新版 - 如果 lock 文件丢失或怀疑过期，先
git checkout composer.lock或从历史记录恢复，再install - 必须
update时，加--with-dependencies控制范围，或用composer update xxx/yyy --with-all-dependencies避免全量升级 - 留意
platform配置：若composer.json里写了"platform": {"php": "8.1.0"}，但当前 PHP 是 8.2，install可能跳过某些仅声明支持 8.1 的包，表现为“找不到”，其实是因为平台约束过滤掉了
镜像源切换后 lock 文件不兼容怎么办
国内常用阿里云、腾讯云镜像，它们同步上游有延迟，且部分私有包不镜像。一旦你之前用官方源生成了 lock 文件，切到镜像源后 install 可能失败。
验证方式很简单：
- 运行
composer config repo.packagist.org，看输出是不是镜像地址（如https://mirrors.aliyun.com/composer/） - 对比 lock 文件里某个包的
dist.url字段：如果是https://api.github.com/...这类直连地址，镜像源通常不代理，就会 404 - 临时切回官方源试一次：
composer config repo.packagist.org https://packagist.org，再install—— 成功说明是镜像问题 - 长期方案：所有团队成员统一源配置，且 lock 文件提交进 Git；避免本地改源后生成新 lock 再提交，否则别人
install会失败
最常被忽略的一点：lock 文件里的 content-hash 是基于 composer.json + 当前源配置 + 平台信息生成的。哪怕只改了一行 repositories，hash 就变，但 Composer 不会报错提示，只会静默失败或降级处理——得靠 -vvv 日志里找蛛丝马迹。
