Composer require 报错本质是依赖约束冲突而非网络问题，需用 composer prohibits 和 why-not 定位阻断源，结合 show 查版本、--dry-run 分析冲突链，避免盲目删锁文件。
Composer require 报错 “Could not find package …” 或 “no matching package found”
这通常不是网络或源的问题，而是 Composer 在当前项目约束下根本找不到满足条件的版本。核心原因：你指定的包版本与 composer.json 中已存在的依赖存在不可调和的约束冲突，或者该包在当前配置的仓库中确实不提供你写的版本号（比如写了 v2.0，但 Packagist 上只有 2.0.0）。
实操建议：
- 运行
composer show -a vendor/package-name看该包是否真有你想要的版本（注意区分dev-main、2.x-dev、^2.0等写法） - 检查
composer.json里"minimum-stability"和"prefer-stable"设置——如果设了"minimum-stability": "stable"，又去 requiredev-develop，必然失败 - 用
composer prohibits vendor/package:version直接定位哪个已有依赖在阻止安装（这是最常被忽略的诊断命令）
require 某个包时触发 “Your requirements could not be resolved”
这是典型的依赖图无法收敛，Composer 尝试了所有组合都找不到一组同时满足所有 require 条件的版本。它不是“没找到包”，而是“找不到兼容解”。
实操建议：
- 先执行
composer update --dry-run，看它尝试解析时卡在哪一步，输出里会明确列出冲突链（例如：package-a v1.2 requires package-b ^3.0，但package-c v4.1 requires package-b ^2.5） - 不要直接删
vendor/或composer.lock——这只会让问题更难复现；应优先用composer why-not vendor/package:version查清阻断来源 - 若必须绕过冲突，可临时加
--with-all-dependencies，但要清楚这意味着强制升级/降级其他包，可能引入运行时风险
require 带版本号却总装成 dev-main 或低版本
常见于用了模糊约束（如 ^1.0）但项目里已有高版本约束的其他依赖，导致 Composer 回退到能共存的最低可行版本；也可能是包本身未打稳定 tag，只有 dev-main 分支。
实操建议：
- 用
composer show vendor/package查看实际可用版本列表，注意dev-开头的是分支别名，不是正式版 - 若想强制装某个具体 tag，写死版本号：比如
composer require vendor/package:2.3.1，而不是2.3.*或^2.3 - 检查该包的
composer.json是否设置了"version"字段（不该设！这是反模式），或是否漏推 Git tag 到远程（Packagist 同步依赖 tag）
require 成功但运行时报 Class not found 或 Method not exists
说明 Composer 装上了，但自动加载或版本行为不一致。典型场景：装了新 major 版本（如从 v1 → v2），但代码仍按旧 API 调用；或 PSR-4 配置未生效，类文件没进 autoload。
实操建议：
- 确认
vendor/autoload.php已被正确引入（尤其在非标准入口脚本中） - 运行
composer dump-autoload -o强制重生成优化后的 autoloader - 检查该包的 CHANGELOG 或 UPGRADE.md，v2 往往有破坏性变更（BC break），比如
SomeClient::send()改成了SomeClient::request()
composer prohibits 和 composer why-not 当成日常命令来用，比反复删 lock 文件有效得多。 
