composer require 失败本质是环境、依赖与版本要求三者冲突，需用 prohibits/why-not 定位根因，而非盲目删缓存或加忽略参数。
Composer require 失败不是“装不上”，而是它明确告诉你：当前环境 + 现有依赖 + 你写的版本要求，三者无法同时满足。 直接删 vendor 或硬加 --ignore-platform-reqs 可能暂时绕过，但问题会复现，甚至更难定位。
报错里出现 “could not be found” 怎么办
这不是网络卡了，大概率是包名或源配置错了。
- 用
composer search vendor/package确认包是否存在（注意大小写和斜杠位置，monolog/monolog≠monolog） - 访问
https://packagist.org/packages/vendor/package看是否返回 404；404 就说明没注册到 Packagist，不能直接require - 运行
composer config -g repo.packagist.org，检查是否被意外清空或指向了不可达的私有源；恢复官方源：composer config -g repo.packagist.org '{"type":"composer","url":"https://packagist.org"}' - 国内用户若用了镜像，先临时切回官方源验证：
composer config --unset repos.packagist && composer require vendor/package
报错里出现 “Your requirements could not be resolved” 怎么定位
这是 Composer 依赖求解器明确告诉你：约束冲突了。别猜，用内置命令挖根。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先跑
composer prohibits vendor/package:version—— 它会列出所有阻止该版本安装的已存在依赖（最常被跳过的诊断动作） - 再跑
composer why-not vendor/package:version—— 显示具体哪个包、哪条requires规则在拦路 - 加
-vvv看完整解析过程：composer require vendor/package -vvv，重点看 “because” 开头的链式提示，比如package-a v2.1 requires package-b ^3.0，但package-c v1.5 requires package-b ^2.4 - 如果报错提到某个扩展（如
ext-dom），运行php -m确认是否加载；没加载就启用对应.ini文件或重装 PHP 扩展
PHP 版本或扩展不匹配导致“not found”或“conflict”
Composer 会静默过滤掉所有不兼容的版本，结果就是“找不到”，实际是“不敢选”。
- 运行
php -v和composer --version，再去目标包的 Packagist 页面点开 “Requires” 标签，核对php和composer-plugin-api字段 - 若本地 PHP 是 8.1，但包要求
"php": "^8.2"，它就不会出现在可选列表里——此时报错看起来就像包不存在 - 临时验证可用性可加
--ignore-platform-reqs，但上线前必须解决真实兼容性，否则运行时可能 fatal error - 项目中若配置了
"config": {"platform": {"php": "8.1.0"}}，而你本地是 8.2，Composer 会按 8.1 解析；删掉该配置再试，前提是代码真兼容 8.2
为什么 clear-cache 和删 vendor/composer.lock 常常没用
缓存和锁文件只是快照，不是病因。盲目清理反而让冲突路径更难追溯。
-
composer clear-cache只影响元数据下载，不改变依赖图逻辑；rm -rf vendor composer.lock后执行composer install，本质是重新走一遍当前composer.json的解析，冲突还在 - 真正该做的是：先用
composer show -a vendor/package看该包实际有哪些版本可选（注意dev-main是分支，不是稳定版） - 如果想装特定 tag，写死版本号：
composer require vendor/package:2.3.1，别用^2.3或2.3.*—— 模糊约束在复杂依赖下极易回退到低版本 - 改
composer.json时，避免锁死小版本（如"foo/bar": "2.3.0"），优先用"^2.3"或"~2.3.0"，给求解器留出调整空间
最易被忽略的一点：Composer v2.2+ 的 prohibits 和 why-not 不是锦上添花，是定位冲突的唯一直通车。不运行它们，就等于在依赖迷宫里闭眼走路。
