清理缓存本身不会改变已安装的依赖版本，因为composer clear-cache仅删除~/.composer/cache/下的下载包、元数据等加速缓存，而真正决定版本的是composer.lock文件、composer.json约束及已执行的install/update命令。

清理缓存本身不会改变已安装的依赖版本——composer clear-cache 只删本地元数据缓存，不影响 vendor/ 和 composer.lock。

composer clear-cache 为什么没让包降级或回退

它只清除 ~/.composer/cache/ 下的包下载缓存（.zip/.tar.gz）、元数据缓存（packages.json、dist metadata）和安装器缓存。这些只是“加速用的副产品”，不是版本决策依据。真正决定装什么版本的是：composer.lock 文件 + 当前 composer.json 的约束 + 已执行的 install/update 命令。

• 如果你刚 clear-cache 就跑 composer install，它会照着 composer.lock 重新下载并解压——哪怕缓存没了，结果也一模一样
• 想换版本？必须改 composer.json（比如把 "monolog/monolog": "^2.0" 改成 "^1.26"），再 composer update monolog/monolog
• 或者直接删掉 composer.lock 再 composer install（仅限开发环境，且确认 composer.json 约束合理）

缓存清理后仍装旧版的常见误操作

你以为清了缓存就能“重来”，但实际生效链路根本没被触发：

Discussion Composer

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

下载

• 执行了 clear-cache，但没运行任何 install/update 命令 → vendor/ 完全不动
• 运行了 composer install，但 composer.lock 里还是旧版本 → 它就只会装旧版，不管缓存有没有
• 用了 composer update --dry-run 看结果，但没加 -v 或没注意输出里的 “Would update” 提示 → 误以为真更新了
• 在 CI 中设置了 COMPOSER_CACHE_DIR 指向临时目录，clear-cache 清的是本地 ~/.composer，CI 用的根本不是那个路径

真正要换依赖版本，该走哪条命令路径

别绕弯子，按目标选最短路径：

• 想严格回到上一个 composer.lock 记录的版本 → git checkout HEAD~1 composer.lock && composer install
• 只想降级某一个包（比如 guzzlehttp/guzzle）→ 先改 composer.json 的版本约束，再 composer update guzzlehttp/guzzle
• 怀疑 composer.lock 被污染或过时 → rm composer.lock && composer install（前提是 composer.json 的约束足够精确，否则可能升到不兼容大版本）
• 需要验证某包是否真能降级 → composer prohibits guzzlehttp/guzzle:7.0 查谁在拦着它

缓存不是版本控制器，composer.lock 才是。清完缓存还看到旧包，不是缓存没清干净，是你还没动真正的开关。