最可靠方式是composer remove vendor/package-name后composer require vendor/package-name:^x.y.z，因install和update默认复用本地文件或缓存，不强制重拉；需手动移除再安装才能确保从网络下载、干净解压并触发钩子。
想让 Composer 重新下载某个已安装的包，不能只靠 composer install 或 composer update —— 它们默认跳过已存在且版本匹配的包。
为什么 composer install 不会重下已安装的包
Composer 把 vendor/ 目录当“事实来源”，只要 composer.lock 没变、包版本在约束范围内，它就直接复用本地文件。删了某个子目录再 composer install，它也只补缺，不重拉整包。
常见现象：
- 改了镜像源，但某个包仍从 packagist.org 下载（
composer.lock里记着旧 dist URL） - 终端没打印
Downloading行，但你以为在重装 - 包的修改时间没变，说明只是硬链接或解压缓存 zip
composer remove + composer require 是最稳的单包重装法
这是唯一能确保“从网络重新拉 zip、干净解压、触发 post-install-cmd”的组合。不是绕路，是设计使然。
操作步骤：
- 运行
composer remove vendor/package-name（注意格式是vendor/package-name，不是package-name） - 再运行
composer require vendor/package-name:^x.y.z，显式指定版本可避免意外升级 - 如果是
require-dev包，加--dev：例如composer require --dev phpunit/phpunit:^10.5
⚠️ 别用 composer update vendor/package-name 替代——它会更新该包及其所有子依赖的版本，可能连带升级 psr/log 或 symfony/polyfill，破坏构建稳定性。
缓存干扰常被忽略：清对应 zip 才算真重拉
Composer 下载前先查 ~/.composer/cache/files/，有旧 zip 就直接解压，根本不去网络。你以为重装了，其实用的是上周缓存的文件。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
快速清理指定包缓存：
- 查缓存路径：
composer config cache-dir - 进缓存目录，按包名搜索：
find $(composer config cache-dir) -name "*vendor-package-name*" - 删掉匹配的
.zip文件（别删整个cache目录） - 再执行
composer require，就能看到Downloading https://...
CI/CD 中漏这步，会导致构建产物看似更新，实则用了缓存里的旧二进制——尤其影响带编译步骤的扩展包（如 ext-redis 绑定的 PHP 版本）。
批量重装所有包？删 composer.lock + composer install
这不是“暴力删除 vendor 再装”，而是让 Composer 丢掉历史锚点，重新解析依赖树、生成新 lock、全量走网络下载。
必须同时做两件事：
-
rm -rf vendor composer.lock（Windows 用rmdir /s vendor && del composer.lock） -
composer install（不是update）
注意：composer update 在 lock 存在时仍是增量行为；只有删 lock 后的 install 才真正从头来。如果还想跳过 dev 包，加 --no-dev；生产环境建议加 --optimize-autoloader。
真正麻烦的从来不是命令敲错，而是 composer.lock 被 Git 忽略、被 IDE 自动恢复、或团队混用 install/update 导致 lock 不一致——这些地方一松懈，问题就藏得特别深。
