composer update 默认复用全局缓存（如~/.composer/cache），优先解压而非重下载；禁用方式有三：--no-cache临时跳过、clear-cache后update彻底清空、或在composer.json中配cache-dir为/dev/null（linux/macos）或nul（windows）实现项目级禁用。
Composer update 为什么会用全局缓存
默认情况下，composer update 会复用 ~/.composer/cache（Linux/macOS）或 %APPDATA%\Composer\Cache（Windows）里的已下载包和 ZIP 归档。这不是“可选功能”，而是 Composer 的默认行为——它优先从缓存解压，而不是重新下载。如果你在 CI 环境、多项目隔离场景，或想验证包真实分发状态，这个缓存反而会导致结果不可靠。
禁用缓存的三种有效方式
注意：不是所有方法都等效，适用场景不同：
-
临时跳过缓存（推荐用于调试/CI）：加
--no-cache参数，例如composer update --no-cache。它会绕过整个缓存层（包括 dist 和 source 缓存），但不清理已有缓存。 -
彻底清空再运行（适合本地验证）：先执行
composer clear-cache，再跑composer update。注意这会影响其他项目，且下次 update 又会重建缓存。 -
项目级禁用（持久但需手动维护）：在
composer.json中添加："config": { "cache-dir": "/dev/null" }Linux/macOS 下生效；Windows 需写成"cache-dir": "nul"。该配置让 Composer 把缓存写入无效路径，实际等效于禁用。但要注意某些旧版本 Composer（nul 支持不稳定。
为什么 --no-cache 不等于 --prefer-source
新手常混淆这两个参数：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
--no-cache关的是「已下载内容的本地复用」，不影响源码来源选择； -
--prefer-source强制从 Git 克隆而非下载 ZIP，它仍会把克隆下来的 repo 缓存在cache/vcs/下，除非同时加--no-cache。 - 真正干净的组合是：
composer update --no-cache --prefer-dist（优先 ZIP 且不缓存）或composer update --no-cache --prefer-source（强制克隆且不缓存克隆结果）。
CI 环境中最稳妥的做法
在 GitHub Actions / GitLab CI 等场景下，仅靠 --no-cache 可能不够——因为某些镜像源或 proxy 会拦截 HTTP 请求并返回缓存响应。所以建议：
- 显式设置
COMPOSER_CACHE_DIR指向一个临时目录，比如export COMPOSER_CACHE_DIR=$(mktemp -d)，避免污染和复用； - 加上
--no-cache和--no-interaction； - 如果使用
composer install（非 update），记得也加--no-cache，否则vendor/安装阶段仍可能读缓存。
缓存机制本身没问题，问题在于你是否清楚它在哪起作用、以及它是否该在当前上下文中起作用。很多“包没更新”“版本不一致”的问题，其实只是缓存没被绕开而已。
