Composer install 报错主因是 composer.lock 与当前环境不匹配，包括镜像源变更、PHP/扩展不兼容、dist URL 失效或 repositories 配置覆盖；应通过 --dry-run 定位失败包、检查 lock 中 dist.url 可访问性、运行 composer check-platform-reqs 验证环境约束。
更新依赖后 composer install 报错，大概率不是命令写错了，而是 composer.lock 和当前环境/配置不匹配——它已经不是“安装”动作，而是在复现一个可能已失效的快照。
为什么 composer install 会突然失败，而 composer update 却成功？
因为 composer update 是重算依赖树、生成新 composer.lock；而 composer install 是严格按 lock 文件还原，哪怕只有一处不满足，就直接报错。常见断点：
-
composer.lock里记录了某个包的 dist ZIP URL（如 GitHub release 地址），但该 release 已被删除或私有化 - 你换了镜像源，但 lock 文件里仍存着旧源的元数据路径，
install尝试去原地址拉包，404 - PHP 版本或扩展变了（比如升级到 PHP 8.3 后，lock 中某包的
php约束是^8.1，但它的 dist 包实际编译依赖mbstring，而你没开这个扩展） - 全局配置被项目级
repositories字段静默覆盖，update时用了新镜像，install却 fallback 到 packagist.org 导致超时或 404
composer install 报 “package x is not installed” 怎么定位？
这不是缺失包，是 lock 文件和 vendor 目录状态不一致。先别删 vendor，用下面命令快速诊断：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 运行
composer install --dry-run：看它卡在哪一个包，是否提示Could not fetch或404 - 检查该包在 lock 中的
dist.url字段：grep -A5 '"name":"vendor/package"' composer.lock，手动curl -I那个 URL 确认是否可访问 - 运行
composer show vendor/package：如果报错 “Package not found”，说明该包根本没进 vendor，但 lock 认为它该存在——大概率是之前install中断残留了部分文件 - 对比
git status：确认composer.lock是否被意外修改过（比如 merge 冲突没清理干净）
换镜像后 composer install 卡在 “Loading composer repositories”
这不是 Composer 在加载，是它试图从 packagist.org 回源——因为你配的镜像没生效，或被项目配置屏蔽了。验证三步：
- 执行
composer config -g repo.packagist，输出必须是完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；若还是https://packagist.org，说明配置失败 - 进项目目录，检查
composer.json里是否有"repositories"字段（哪怕只是空数组[]），有则全局镜像完全失效 - 运行
curl -v https://mirrors.aliyun.com/composer/packages.json 2>&1 | grep "HTTP/2 200"，确认镜像本身可连通；若卡在 TLS handshake，可能是 CA 证书过期，需更新cacert.pem并配置openssl.cafile
报错 “Your requirements could not be resolved” 却刚跑过 update
说明 composer.lock 里锁死的版本组合，在当前环境下已不可行——最常见于 PHP 版本升级或扩展禁用后。不要直接删 lock，先做两件事：
- 运行
composer check-platform-reqs：立刻暴露缺失的 PHP 版本、扩展或 ini 设置（如memory_limit） - 运行
composer why-not php:8.3（换成你当前 PHP 版本）：看哪个直接依赖硬性要求更低版本，比如laravel/framework还没升到支持 8.3 的版本 - 如果只是临时验证，加
--ignore-platform-reqs绕过检查（仅调试，勿提交）
真正容易被忽略的是：lock 文件不是“一次生成，永久有效”的快照，它隐式绑定了 PHP 版本、扩展、镜像可用性、甚至 GitHub release 存续状态。每次 composer update 后，都该用 composer install --dry-run 在目标环境快速过一遍，而不是等 CI 或上线时才暴露。
