Composer 没有中心化索引，所谓“刷新”实为绕过缓存重新拉取元数据和ZIP包；update不生效主因是默认复用本地缓存的packages.json和ZIP文件，需用--no-cache、clear-cache或COMPOSER_CACHE_DIR=/dev/null等方法强制走网络请求。

Composer 不会“刷新索引”，它压根没有中心化索引服务；所谓“强制刷新”实际是绕过本地缓存，让 composer install 或 composer update 重新拉取包元数据和 ZIP 文件。

为什么 composer update 有时不生效？

常见现象：你刚 push 了新 tag 到 GitHub，但 composer update 仍装旧版本，甚至提示 Nothing to install or update。这不是 Composer “卡住了”，而是它默认复用本地缓存的 packages.json（来自 packagist.org 的元数据快照）和已下载的 ZIP 包。

• Composer 缓存分两层：HTTP 响应缓存（~/.composer/cache/repo/https---packagist.org/）和 ZIP 包缓存（~/.composer/cache/files/）
• 即使远程包更新了，只要缓存未过期（默认 15 分钟），Composer 就不会重新请求 packages.json
• composer update 默认只检查缓存中的元数据，不强制刷新网络源

真正有效的强制刷新方法（三选一）

按推荐顺序排列，优先用最轻量、最明确的方式：

Discussion Composer

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

下载

• 仅刷新元数据（最常用）：运行 composer clear-cache && composer update --no-cache。--no-cache 会让本次命令跳过所有本地缓存（包括 repo 和 files），但不会清空磁盘缓存；clear-cache 是保险动作，确保下次也干净
• 只针对某个包强制重拉：用 composer update vendor/name --with-dependencies --no-cache，避免全量更新拖慢速度；注意 --with-dependencies 要加，否则依赖可能被锁在旧版本
• 彻底禁用缓存（调试用）：设环境变量 COMPOSER_CACHE_DIR=/dev/null 再执行命令，例如 COMPOSER_CACHE_DIR=/dev/null composer update；这会让所有缓存写入失败，等价于全程走网络（慎用于 CI 外的日常开发）

别踩这些坑

很多人试过但无效的操作，其实根本没碰对缓存点：

• composer dump-autoload 只重建自动加载映射，和包元数据无关
• 删 vendor/ 和 composer.lock 后直接 composer install —— 它仍会读 lock 里的旧 commit/tag，不会去 fetch 新版
• 改 composer.json 里 version 约束为 "dev-main" 却不加 --no-cache，结果还是拉到缓存里的旧 dev 分支快照
• 以为 composer self-update 能刷新包索引 —— 它只升级 Composer 二进制本身

关键记住一点：Composer 的“源”是 HTTP 接口返回的 JSON，不是本地数据库。所谓刷新，就是让它放弃缓存响应，重新发一次 GET 请求。真正的瓶颈往往不在网络，而在你没告诉它“这次请别看缓存”。