Composer解析失败主因是依赖路径与锁文件状态混乱或平台配置错位，而非版本错误；composer why无输出说明该包未被当前项目直接或间接必需引用，可能属dev依赖、可选依赖或被--no-dev跳过。
复杂项目里 Composer 解析失败，90% 不是版本写错了，而是依赖路径没理清、composer.lock 状态混乱、或平台配置和实际运行环境错位。别急着改版本号，先查路径、看锁文件、核对 PHP 版本。
composer why package-name 没输出？说明它不是当前依赖树的必需节点
执行 composer why monolog/monolog 返回空，并不表示这个包没装上，只代表它没被 require 或任何已启用依赖链直接拉进来。
- 先确认是否真在
vendor/下：ls vendor/monolog/monolog - 查它怎么进来的：
composer show -t | grep monolog，看是否藏在某个require-dev包底下（比如phpunit/phpunit依赖了它） - 如果只在
require-dev声明，而你用composer install --no-dev部署，那它压根不会装——why自然无话可说 - 想强制检查所有已安装包的来源，加
-v：composer why -v monolog/monolog
composer update 卡住或反复降级？优先核对 platform 配置与真实 PHP 版本
常见现象：明明 composer.json 写着 "php": "^8.1"，但 update 后却装了 symfony/console:v5.x（只支持 PHP 7.2+），而不是 v6.x（要求 PHP 8.0+）。这不是算法 bug，是 Composer 默认按当前运行环境的 PHP 版本做约束裁剪。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 执行
php -v—— 看的是部署机或 CI 容器里的版本，不是你本地开发机的 - 临时诊断可用：
composer update --ignore-platform-reqs，但切勿提交到 CI 脚本 - 更稳妥的做法是在
composer.json的config段声明目标平台："config": { "platform": { "php": "8.1.10" } }让解析器按此基准计算，而非读取运行时
多个包依赖同一库的不同主版本（如 ^2.0 和 ^3.0），为什么没报错？
Composer 不强制所有依赖收敛到同一个主版本号；它只保证存在一个**同时满足所有约束表达式**的最高兼容版本。
- 例如：
packageA要求psr/log:^1.0，packageB要求psr/log:^2.0，而psr/logv2.x 向下兼容 v1.x 接口（PSR 规范本身允许），那么 Composer 就会选 v2.x 并成功安装 - 关键判断依据不是「主版本号是否相同」，而是「是否存在一个版本能同时满足所有约束」
- 若真冲突，错误信息会明确写出：
Root package requires psr/log ^1.0, packageB requires ^2.0 → can only install one of: psr/log[1.0.0, ..., 1.1.4], psr/log[2.0.0, ...] - 排查谁排除了某版本：
composer prohibits psr/log:1.0.0
vendor/autoload.php 加载失败，Class not found？先看 autoload 配置和 dump-autoload 是否生效
类找不到，未必是路径错了，很可能是自动加载没注册或没优化。
- 确保
composer.json中autoload段正确映射命名空间，例如："autoload": { "psr-4": { "App\": "src/" } } - 修改后必须执行：
composer dump-autoload（开发时）或composer dump-autoload -o（生产部署，生成优化类映射） - 如果用了
classmap或files类型，注意它们不会随文件增删自动更新，需手动重跑dump-autoload - 检查是否误把私有类放在
require-dev包里，又在生产环境跳过了安装
复杂项目最易忽略的点是：把 composer.lock 当作“版本快照”就完事，其实它还隐含了平台约束、依赖路径状态、甚至 dev-only 包的安装痕迹。每次 update 前，先 git diff composer.lock 看变化范围；每次部署前，确认 --no-dev 和 -o 是否都到位。
