“Class not found”是次级依赖版本不匹配所致，根源在于composer.lock记录版本与实际安装版本不一致，常见于未同步更新lock文件或禁用平台检查；需用composer show和composer why-not精准定位冲突链。

composer install 报错 “Class not found” 是次级依赖版本不匹配的典型症状

这不是 autoload 问题，而是 composer.lock 里记录的次级依赖（比如 symfony/http-client-contracts）和当前已安装的包实际版本对不上。常见于你改了 composer.json 后只跑 composer update，但没同步更新 composer.lock；或者团队共用 lock 文件，但本地 PHP 版本、扩展或平台配置不同，导致 Composer 在 install 阶段跳过某些约束校验，装了不兼容的子依赖。

• 运行 composer show symfony/http-client-contracts 查看实际装的版本，再对比 composer.lock 里该包的 version 字段
• 如果两者不一致，说明 composer install 没严格按 lock 文件还原 —— 很可能因为你本地启用了 --ignore-platform-reqs 或 platform-check 被禁用
• 不要手动删 vendor/ 后直接 composer install：先确认你正在用目标 commit 的 composer.lock，否则它会按你当前 composer.json 重算，不是“回滚”

为什么 composer update 不降级次级依赖

composer update 默认只升不降，哪怕你在 composer.json 里把 monolog/monolog 改成 "^2.9"，它也不会主动把 psr/log 从 3.0 降回 1.2 —— 因为 psr/log 没被你显式声明，Composer 认为它是“已满足的稳定状态”，不会主动破坏。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 真正能触发次级依赖调整的，只有 composer require vendor/package:version --with-all-dependencies
• --with-all-dependencies 不是可选开关：它强制求解器重走整条依赖链，连 phpunit/phpunit 这类 require-dev 包也会参与计算
• 漏掉这个 flag，composer require monolog/monolog:2.9.2 可能成功，但 symfony/console 还卡在 6.x，运行时直接报 Class not found

composer why-not 才是定位次级冲突的唯一有效命令

报错末尾的 Conclusion: don't install guzzlehttp/guzzle:^8.0 是求解器放弃后的结果，不是原因。真正阻断链藏在嵌套依赖里，必须用 composer why-not 穿透。

• 必须带完整版本标识：composer why-not guzzlehttp/guzzle:^7.5，写成 guzzlehttp/guzzle 或 guzzlehttp/guzzle:7.5 都会报 Package not found
• 输出从下往上读：最后一行是你 composer.json 的根声明（如 myapp/core dev-main requires guzzlehttp/guzzle (^6.5)），往上每行都是某个已安装包写的约束
• 注意 require-dev 包也参与解析 —— phpunit/phpunit 要求 php: ^8.0，而你本地是 7.4，整个链就卡死在起点

降级后验证 version 字段必须精确匹配

composer show monolog/monolog 输出的 version 必须是 2.9.2.0，不是 2.9.2。Composer 自动补零，但 2.9 和 2.9.2 解析行为不同 —— 前者等价于 ^2.9.0，后者是精确版本锚定。如果输出是 2.9.0.0，说明降级没生效。

• 先确认目标版本存在：composer show -a monolog/monolog 查 2.9.2 是否标记为 abandoned 或 unstable
• 执行降级命令前，确保没启用 "minimum-stability": "stable" —— 否则 dev 分支版本根本不会进候选池
• 如果 composer why-not 输出为空，不是没冲突，而是该版本不在当前 Packagist 通道（比如你设了 stability 限制，但目标版是 RC）

实际操作中最容易忽略的是：次级依赖的兼容性不是由你声明的包决定的，而是由整个依赖图里最严格的那个 conflict 或 require 规则决定的 —— 它可能来自你从未直接 require 过的包。