红字末尾那行才是关键线索：如“your requirements could not be resolved”表明依赖逻辑冲突，“conclusion: don’t install”需用composer why-not定位拦路包，“file could not be downloaded”应切镜像并清缓存，“permission denied”须修复vendor属主，而“fatal error”等仅在-vvv下可见，指向运行时问题。
红字末尾那行才是关键线索
Composer 报错时满屏红字，但真正有用的只有一行，通常在最后或倒数几行。别扫全屏，直接跳到末尾看带冒号的那句——它决定了你该往哪个方向查。
常见关键词和对应含义：
-
Your requirements could not be resolved：依赖约束逻辑矛盾，和网络、权限无关 -
Conclusion: don't install symfony/console:^6.4：Composer 已算出该版本不可用，下一步必须跑composer why-not symfony/console:^6.4 -
file could not be downloaded：PHP 拿不到远程元数据，优先切镜像 + 清缓存 -
Permission denied：vendor/ 所有者不是当前用户，常见于误用sudo composer install -
Fatal error: Uncaught Error或ParseError：脚本执行崩溃，只在-vvv下可见
为什么 -vvv 是必加参数
默认情况下 Composer 会吞掉子进程的 stderr，你只看到 “Script failed with error code 1”，却不知道哪行 PHP 崩了。加 -vvv 后，它会原样打出每条执行命令、环境变量、以及真实错误堆栈。
特别注意：
- 如果脚本是 PHP 文件，检查开头是否有
#!/usr/bin/env php和可执行权限（Linux/macOS） - Windows 上推荐显式写
"php script.php"，避免系统找不到解释器 -
-vvv输出里一旦出现Fatal error或Class not found，说明问题不在依赖解析，而在运行时环境或代码本身
composer why-not 怎么用才不白跑
这个命令不是辅助选项，是唯一能穿透多层依赖、直击阻塞点的工具。它不猜、不试、不删文件，只输出真实依赖链。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
操作要点：
- 报错说装不上
monolog/monolog:^2.0，就执行composer why-not monolog/monolog:^2.0 - 输出最顶上那一行（如
myproject dev-main requires laravel/framework (9.0)）才是你该改的地方，不是下面层层嵌套的传递依赖 - 如果输出里出现
abandoned包，说明某依赖已停更，得去 Packagist 页面查推荐替代包，而不是硬升版本 - 不确定变更影响时，先加
--dry-run：例如composer update monolog/monolog --dry-run
别让多个问题叠加掩盖真相
真正麻烦的不是单个报错，而是多个条件同时存在：比如你用旧镜像源触发了 404，Composer 却因权限问题无法写入缓存，最终报出一个看似是依赖冲突的假象。
排查顺序建议按真实发生路径来：
- 先看红字末尾关键词 → 定性问题类型
- 再加
-vvv确认是否真有远程请求失败或脚本崩溃 - 如果是依赖冲突，立刻
composer why-not，别碰vendor/或composer.lock - 如果是权限或网络类错误，再处理属主、镜像、CA 证书等底层环节
复杂点在于：同一个错误信息可能由不同原因触发，比如 Permission denied 可能是 vendor 属主不对，也可能是 Windows 下文件被 IDE 锁住。所以不能只看字面，得结合 -vvv 输出和上下文判断。
