答案是目标版本未进入Composer元数据索引，常见于VCS仓库场景：Composer默认缓存dist或Git快照，不实时拉取分支composer.json，导致本地修改未生效；需确认仓库URL为HTTPS、分支名匹配、composer.json字段完整，并清VCS缓存或强制重读元数据。
composer why-not 为什么查不到阻断源？
输出为空，不是命令写错了，而是目标版本根本没进 Composer 的元数据索引——尤其常见于 VCS（Git）仓库场景。Composer 默认只缓存 dist 包或 Git 快照，不会实时拉取分支最新 composer.json，所以你改了本地 composer.json 里的 require 或 conflict，why-not 仍查不到变化。
实操建议：
- 加
-vvv运行composer why-not vendor/package:dev-main，看日志是否出现Reading /path/to/repo/composer.json；若只显示Using version x.x.x from cache，说明缓存没刷新 - 确认 VCS 仓库 URL 是完整 HTTPS 地址（如
https://github.com/vendor/package.git），不能是本地相对路径或 SSH 格式（git@...），否则 Composer 不走 VCS 解析逻辑 - 如果用的是
dev-main，确保远程分支名确实是main（不是master），且该分支下composer.json中的name和version字段与主项目require声明完全一致
VCS 元数据未更新导致子依赖丢失
本地 Git 仓库被当作 VCS 源时，Composer 会从该仓库的 composer.json 提取 require、conflict 等字段来构建依赖图。但若你只提交了代码、没推 composer.json 变更，或 Satis 类工具未启用元数据继承，composer install 就只装顶层包，不装它声明的 illuminate/support 这类子依赖——结果就是 Class not found。
实操建议：
- 手动访问 VCS 仓库的 raw URL（如
https://raw.githubusercontent.com/vendor/package/main/composer.json），确认require字段存在且非空 - 在主项目中运行
composer show vendor/package，检查输出里是否有source: git ...行；没有则说明没走 VCS 模式，可能被repositories配置覆盖或忽略 - 若用 Satis，必须在
satis.json中显式启用"providers": ["*"]并配置"require-dependencies": true（部分旧版需补全require字段映射）
删 vendor 不解决 VCS 缓存问题
rm -rf vendor/ 后再 composer install，依然装错版本，是因为 Composer 重用了 ~/.composer/cache/vcs/ 下的 Git clone 快照，甚至可能复用旧 commit 的 composer.json 内容。这不是锁文件问题，也不是网络问题，是 VCS 缓存污染。
实操建议：
- 清 Git 缓存：Linux/macOS 执行
rm -rf $(composer config --global cache-dir)/vcs/*；Windows 用户去%APPDATA%\Composer\Cache\vcs\手动删空 - 强制重读元数据：删掉
vendor/vendor/package目录（不是整个vendor），再跑composer update vendor/package --no-cache - 验证是否生效：加
-v参数运行，日志中应出现Cloning [commit-hash] from [url]，而不是Using cached clone
为什么 composer update 卡在 “Resolving dependencies”？
这不是慢，是 SAT 求解器正在穷举所有 VCS 分支 + tag + commit 的组合，尤其当多个包都指向同一 Git 仓库的不同分支（比如一个 require dev-main，另一个 require dev-develop），而它们的 composer.json 又对 PHP 版本或 monolog/monolog 提出互斥约束时，解析可能卡住数分钟甚至超时。
实操建议：
- 先固定分支：把
"vendor/package": "dev-main"改成带 commit hash 的精确引用，如"vendor/package": "dev-main#abc1234"，避免 Composer 自动找最新 commit - 临时禁用 VCS 源：注释掉
repositories里的 VCS 条目，切回 Packagist 或 dist 模式，用composer show --tree快速定位真实冲突链 - 别信
--dry-run的“成功”反馈——它不校验 VCS 元数据是否可解析，只模拟 lock 文件生成，实际install仍可能失败
VCS 缓存的问题核心不在“快不快”，而在“信不信”。Composer 对 Git 仓库的信任建立在元数据完整性上，一旦缓存、分支名、composer.json 字段三者任一脱节，它就只能靠猜——而猜错的代价，是整个依赖树崩塌。
