直接运行composer clear-cache只清全局缓存，不影响项目运行；但若要更新包版本或解决拉取失败，必须同步处理composer.lock和vendor/——单独清缓存几乎无效，因其不修改lock文件中锁定的版本号与校验值，install仍严格按lock执行。
直接运行 composer clear-cache 只清全局缓存，不影响项目运行；但若要更新包版本或解决拉取失败，必须同步处理 composer.lock 和 vendor/ —— 单独清缓存几乎无效。
为什么 composer clear-cache 后还是装旧版？
根本原因不是缓存没清干净，而是 composer.lock 锁死了版本号。Composer 优先读 lock 文件里的 dist.sha256 和 version，哪怕缓存全空、镜像已更新，它也只按 lock 装。
-
composer.lock是“安装契约”，不是缓存，clear-cache完全不碰它 - 执行
composer update才会重算依赖并更新 lock；install只照单执行 - 私有源或新发布包延迟出现，常因
~/.composer/cache/repo/https---packagist.org/里元数据过期，clear-cache会删这部分，但首次update仍可能复用旧快照
遇到 Failed to extract 或 Corrupted zip file 怎么办？
这类错误基本是 ~/.composer/cache/files/ 下某个 ZIP 文件损坏（比如断网中断下载），而 Composer 不会自动跳过或重试，只会卡死。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先定位：跑
composer install -v，看最后一行Extracting后跟的包名，例如symfony/console - 查缓存路径：
composer config --global cache-dir，进files/子目录，用包名模糊搜索：ls *symfony*console*.zip（Linux/macOS）或 PowerShell 中Get-ChildItem "$env:APPDATA\Composer\Cache\Files" -Filter "*console*.zip" - 只删匹配的 ZIP，别动
repo/或vcs/—— 它们不参与解压流程 - 删完 ZIP 还报错？说明
composer.lock里记录的dist.sha256和当前缓存不匹配，必须同步删vendor/和composer.lock，再跑composer install --no-cache --force-checksums
CI/CD 里清缓存卡住或失效怎么办？
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 挂载点而非本地磁盘） - 镜像配置三要素必须全对：键名是
repo.packagist（不是repos.packagist），type 必须显式写composer，URL 结尾不能少斜杠，例如composer config -g repo.packagist composer https://mirrors.aliyun.com/ - 如果仍卡住，可能是后台 PHP 进程锁着缓存目录：
lsof +D $(composer config --global cache-dir)（Linux/macOS）或用handle.exe -p php.exe（Windows，需 Sysinternals）查占用
手动删缓存比 clear-cache 更危险，但有时更必要
clear-cache 会跳过正被占用的文件，相对安全；手动 rm -rf 不判断，删到一半被写入，后续可能报 Corrupted cache file。
- 最常需要手动干预的是
vcs/目录：它默认被clear-cache跳过，但单个 Git 裸仓库就占 300–800 MB，还耗尽 inodes，必须手动清：rm -rf ~/.composer/cache/vcs/*（Linux/macOS）或rd /s /q "%APPDATA%\Composer\Cache\vcs"（Windows） - 临时目录
sys_get_temp_dir()下堆积的composer_*.zip、php*.phar，clear-cache完全不碰，得自己进/tmp或%TEMP%清 - 权限错乱很常见：之前用
sudo composer install写过缓存，现在普通用户运行clear-cache就会被拒绝删除，得先sudo chown -R $USER ~/.composer/cache
真正麻烦的从来不是“怎么删”，而是删完之后要不要重装、从哪重装、lock 文件和 vendor 是否一致——这三个东西只要漏掉一个，就白忙活。
