清理 Composer 缓存本身不提升下载效率，只影响重试成功率和首次安装耗时；真正拖慢下载的是镜像未生效、缓存损坏或 vendor/ 锁定旧源——需先确认问题类型再决定是否清缓存。
清理 Composer 缓存本身不提升「下载效率」，它只影响「重试成功率」和「首次安装耗时」；真正拖慢下载的是镜像未生效、缓存损坏或 vendor/ 锁定旧源——先确认问题类型，再决定是否清缓存。
缓存清理前必须确认的三件事
很多人清完缓存发现没变化，是因为根本没对症：
- 运行
composer config --global cache-dir查真实路径，别默认去~/.composer/cache——COMPOSER_CACHE_DIR环境变量或公司镜像可能已改写它 - 用
du -sh $(composer config --global cache-dir)（Linux/macOS）或右键资源管理器属性（Windows）看实际体积：不到 200 MiB 基本不用管；超 1.5 GiB 且半年没碰老项目才值得动手 - 执行
composer install -vvv观察日志：如果卡在Downloading https://packagist.org/或反复重试，说明镜像失效；如果停在Extracting vendor/symfony/console并报Corrupted zip file，才是缓存损坏真问题
只删损坏 ZIP 文件，别全量清缓存
看到 Failed to extract 或 zlib_decode() error，本质是 ~/.composer/cache/files/ 下某个 ZIP 下载中断或写坏。全量清缓存反而延长恢复时间：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 从
composer install -v日志末尾找报错包名，比如symfony/console - 进
~/.composer/cache/files/，用ls -l *symfony*console*.zip（Linux/macOS）或 PowerShell 的Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Filter "*console*.zip"定位匹配 ZIP - 仅删除该 ZIP，不碰
repo/和vcs/——它们不参与解压流程 - 删完必须同步删
vendor/和composer.lock，否则dist.sha256校验仍失败
metadata 更新滞后？光 clear-cache 不够
执行 composer update 拉不到新版本，常因元数据缓存陈旧。但 composer clear-cache 默认不刷新远程索引：
-
composer clear-cache只清files/、repo/、vcs/子目录，而 Packagist 元数据实际存在~/.composer/cache/repo/https---packagist.org/下的packages.json和provider-*.json - 需手动删掉整个
~/.composer/cache/repo/https---packagist.org/目录 - 同时删
vendor/composer/installed.json（当前安装快照）和composer.lock（锁定约束） - 最后跑
composer update --dry-run -v，看到Downloading https://packagist.org/packages.json才算真正刷新成功
CI/CD 中清缓存卡住？加 --no-interaction 是底线
GitHub Actions、GitLab CI 等无交互环境里，composer clear-cache 默认会等待确认，直接 hang 住：
- 必须加
--no-interaction：例如composer clear-cache --no-interaction - 建议先加
--dry-run预检：composer clear-cache --no-interaction --dry-run，确认输出路径是否指向预期位置（比如 NFS 挂载点而非本地磁盘） - 若仍卡住，检查是否有后台进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS），或用handle.exe -p php.exe（Windows，需 Sysinternals） - 容器化部署中，
cache-read-only: true配置比频繁清理更稳妥，避免写冲突
缓存不是越勤清越好——新版 Composer 对压缩包复用和元数据增量更新更聪明，盲目清理反而放大首次安装延迟；真正该盯的是镜像配置是否生效、composer.lock 是否过期、以及 vcs/ 目录是否悄悄吃掉几百 MB 空间还耗尽 inode。
