必须同时删vendor、删composer.lock、执行composer clear-cache、再运行composer install --no-cache——四步缺一不可；否则composer仍会复用锁文件或缓存，仅“复原”而非真正重下载。

必须同时删 vendor、删 composer.lock、执行 composer clear-cache，再加 --no-cache 运行 composer install——四步缺一不可。只做其中两三步，90% 的情况仍是“假重装”。

为什么 composer install 总是不真正重下包？

Composer 默认完全信任 composer.lock 和本地缓存（~/.composer/cache/ 或 %APPDATA%\Composer\Cache\）。它不会发 HTTP 请求，而是直接从缓存解压 ZIP 包，再按 lock 文件里的哈希值校验还原。删了 vendor 目录？它照样复原。清了缓存？下次 install 仍会立刻重建并复用旧记录。

常见错误现象：composer install -v 日志里没出现 Downloading，只有 Using cache 或 Extracting archive；某个包行为异常，但代码没变——极可能是缓存 ZIP 本身损坏或镜像滞后。

删 vendor 和 composer.lock 是硬性前提

二者必须一起删，顺序无关，但缺一不可：

Discussion Composer

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

下载

• 只删 vendor：Composer 仍严格按 composer.lock 复原，不是重装
• 只删 composer.lock：Composer 可能拒绝执行 install，或报错 No composer.lock file present
• Linux/macOS：rm -rf vendor composer.lock
• Windows（PowerShell）：Remove-Item -Recurse -Force vendor, composer.lock

注意：composer.lock 是版本依据，删之前务必确认已提交到 Git，否则重生成的 lock 可能和线上环境不一致。

composer clear-cache 和 --no-cache 是互补关系，不是替代

composer clear-cache 只是清掉 ~/.composer/cache/ 下的 ZIP、tar.gz 和元数据；--no-cache 才是告诉 Composer “这次别查缓存目录，老老实实发 HTTP 请求”。两者必须配合使用：

• 不运行 clear-cache：缓存 ZIP 仍在，--no-cache 会跳过缓存查找，但网络请求可能命中 CDN 或镜像源的旧响应
• 只运行 clear-cache 不加 --no-cache：Composer 会在安装前自动重建缓存，并立刻复用旧哈希
• 正确顺序：composer clear-cache → 确认输出含 Clearing cache (all) → 紧接着 composer install --no-cache
• CI/CD 中更稳妥：COMPOSER_CACHE_DIR=/dev/null composer install --no-cache，彻底绕过缓存路径

容易被忽略的关键点

私有仓库凭据、平台配置、镜像源设置这些不会被 clear-cache 清除，但会影响 --no-cache 下的真实请求结果。比如你切回官方源调试，却忘了改 composer.json 里的 repositories，那下载的仍是私有镜像里的旧包。另外，composer.lock 里记录的是 PHP 版本、扩展等平台信息，若你刚升级 PHP，不删 lock 文件就跑 install --no-cache，仍可能因平台不匹配导致部分包跳过安装或报错。