Composer缓存不自动清理旧版本包，clear-cache会清空全部缓存而非精准删除未被lock引用的归档；需手动结合jq与find筛选并删除冗余zip文件。
Composer 缓存里不会长期“积压”旧版本包，所谓“清除旧版本依赖包”本质是清理本地下载缓存（~/.composer/cache）中已不再被任何 composer.lock 引用的归档文件，或解决因缓存损坏导致的安装异常。直接删缓存不等于清理项目依赖，也不会影响 vendor/ 或自动加载。
为什么 composer clear-cache 不能精准删“旧版本”
该命令清空的是整个缓存目录，包括：HTTP 请求响应、zip/tar 归档、vendor 包解压快照、甚至部分插件缓存。它不区分“是否还在用”，也不扫描 composer.lock 去比对哪些版本已弃用。执行后所有后续 composer install 都会重新下载——对 CI 或低带宽环境不友好。
- 缓存本身无“版本生命周期”管理，Composer 不记录哪个 zip 对应哪个项目的哪次 lock
- 同一个包的不同版本（如
monolog/monolog:2.10.0和3.5.0）可能共存于缓存，只要曾被某个项目拉过 - 真正“冗余”的判断依据在项目级：
composer.lock里没写的版本，才叫旧；但缓存不会主动识别这个
想只删 lock 文件里没用到的包归档？得手动筛
Composer 没提供内置命令做这件事，但可用脚本结合 composer.lock 和缓存结构清理。核心逻辑是：提取 lock 中所有 dist.shasum 或 dist.url 的哈希/路径，反向匹配缓存里的归档名。
- 先确认缓存位置：
composer config cache-dir（通常是~/.composer/cache） - 提取当前项目用到的所有 dist 哈希：
jq -r '.packages[] | .dist.shasum' composer.lock 2>/dev/null | sort -u > used-hashes.txt - 列出缓存中所有 zip 归档的哈希：
find ~/.composer/cache/files -name "*.zip" -exec sha256sum {} \; | awk '{print $1}' | sort -u > all-hashes.txt - 算差集并删对应文件：
comm -13 used-hashes.txt all-hashes.txt | while read h; do find ~/.composer/cache -name "$h.zip" -delete; done
⚠️ 注意：jq 必须已安装；该操作不清理 repo 类缓存（如 packagist.org 元数据），那些可安全忽略。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
缓存损坏时的典型症状和修复动作
真正需要清缓存的场景，往往不是“有旧包”，而是“装不上新包”或“校验失败”。常见错误包括：
-
file could not be downloaded: failed to open stream: Connection refused→ 网络代理或镜像源失效，优先改composer config repo.packagist.org.url -
Invalid archive signature或sha256 hash mismatch→ 缓存 zip 损坏，此时composer clear-cache是必要操作 - CI 中反复
composer install失败，且--no-cache后成功 → 说明本地缓存污染，必须清
执行 composer clear-cache 后，建议立刻跑一次 composer install --no-dev 验证基础依赖能否正常落地，避免缓存清完却暴露了 lock 文件本身的问题。
最常被忽略的一点：缓存只是下载加速层，它不影响 composer.json 和 composer.lock 的语义正确性。与其花时间筛“哪些旧版本该删”，不如定期运行 composer outdated 看哪些包真该升级或移除——那才是项目依赖健康度的真实信号。
