Composer 会复用本地缓存（如 ~/.composer/cache/）导致 install/update 仍用旧包；需执行 composer clear-cache 彻底清理，并验证 downloads/ 是否为空及日志是否显示 Downloading。
composer install 或 update 依然用旧包，缓存没清干净
Composer 默认会复用 vendor/ 和本地包缓存（~/.composer/cache/），哪怕你删了 vendor/、清了 composer.lock，它仍可能从缓存拉旧版本的 zip 包或已解压的 dist 包。这不是 bug，是设计使然——但恰恰是「强制重下」最常卡住的地方。
- 先确认缓存位置：
composer config --global cache-dir - 彻底清缓存：
composer clear-cache（它会清cache-dir下所有内容，包括repo/、files/、downloads/） - 清完立刻验证：进缓存目录，看
downloads/是否为空；再跑composer install -v，观察日志里是否出现Downloading ...而非Using cache
用了 --no-cache 但还是没重下 dist 包
--no-cache 只禁用远程仓库元数据缓存（比如 packagist.org 的包列表），不影响已下载的 dist 包（zip/tar.gz）或源码克隆。想绕过 dist 缓存，得配合 --prefer-source 或强制跳过 dist。
- 强制走 git clone（不依赖 zip）：
composer install --prefer-source - 彻底禁用 dist 下载（只允许 source）：
composer config --global prefer-stable false && composer config --global github-protocols ["https"]，再加--prefer-source - 如果只想清 dist 缓存不碰 source：
rm -rf $(composer config --global cache-dir)/downloads/*
CI/CD 环境里反复 install 却总用旧包
CI 脚本里常见写法是 composer install + 缓存 vendor/，但缓存 vendor/ 本身就会让后续构建跳过安装逻辑——哪怕 composer.lock 已更新。这不是 Composer 的错，是缓存策略和命令顺序冲突。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 中不要缓存整个
vendor/，改缓存~/.composer/cache/（更安全，且clear-cache可控） - 确保每次构建都带
--no-interaction --optimize-autoloader --ignore-platform-reqs，避免因交互或平台检查中断 - 若必须重装，用
rm -rf vendor/ && composer install，别省那几秒
composer update 没生效，实际更新的是另一个分支或版本
运行 composer update 时，如果 composer.json 里某个包写的是 "monolog/monolog": "^2.0"，而你本地 vendor/ 里已是 2.10.0，它就不会动——哪怕你刚在 GitHub 上发布了 2.11.0。Composer 不会自动 fetch 最新 tag，除非版本约束允许且远程有新匹配。
- 查当前装的版本：
composer show monolog/monolog - 查远程可用版本：
composer show -a monolog/monolog - 强制更新到最新符合约束的版本：
composer update monolog/monolog --with-all-dependencies - 如果要硬切到某 commit：
composer require monolog/monolog:dev-main#abc123（注意#后是 commit hash）
真正麻烦的不是命令记不住，而是你以为清了缓存、删了 vendor、跑了 update，结果 Composer 在背后悄悄复用了某个你根本没注意到的缓存层——比如 ~/.composer/cache/files/ 里的解压后代码，或者 CI 里被误命中的 vendor 缓存。动手前，先 ls -la $(composer config --global cache-dir) 看一眼，比瞎试三次更省时间。
