Composer默认启用全局包缓存，路径为Linux/macOS的~/.composer/cache或Windows的%LOCALAPPDATA%\Composer\cache；运行composer config --global cache-dir可查看当前路径，若为空或报错则缓存可能被禁用。
Composer 默认就启用了全局包缓存，不需要额外配置——但很多人根本没意识到它在工作，或者误操作把它关了、清空了，结果每个项目都重复拉取 vendor 里的相同 ZIP 包，白白浪费磁盘和时间。
缓存目录在哪？怎么确认它真在用
Composer 把下载的 ZIP 包（不是解压后的代码）统一存在用户级缓存目录里，路径由 COMPOSER_CACHE_DIR 环境变量控制；没设的话，默认是：
- Linux/macOS：
~/.composer/cache - Windows：
%LOCALAPPDATA%\Composer\cache
运行 composer config --global cache-dir 能直接看到当前生效路径。如果输出为空或报错，说明缓存可能被禁用。
为什么你的项目还在重下包？常见关闭缓存的操作
缓存失效往往不是默认行为，而是人为干预导致的：
- 执行过
composer config --global cache-dir ""（把路径设为空字符串） - 设置了
COMPOSER_CACHE_DIR=/dev/null或类似无效路径 - CI 环境中加了
--no-cache参数，或 CI 配置里显式禁用了缓存 - 使用了旧版 Composer（
检查是否启用：运行 composer config --global cache-dir，有合理路径输出即为开启；再看该目录下是否有 files/ 子目录和大量哈希命名的 ZIP 文件，那就是缓存正在工作。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
composer install 和 composer update 缓存行为差异
两者都优先从缓存读 ZIP，但触发下载的条件不同：
-
composer install：只查composer.lock中记录的 exact version + hash，命中缓存就直接解压，不联网 -
composer update：先查缓存，但若缓存里没有对应版本（比如第一次更新某个包），会去远程仓库获取最新composer.json，再决定下载哪个 ZIP —— 这步仍可能触发新包下载，但后续 install 就能复用 - 注意：
composer require foo/bar等同于 update 行为，不是 install
所以多个项目共用同一份 lock 文件（如模板项目），install 时缓存复用率最高；而每个项目各自 update，首次仍需下载，但之后所有项目都能受益。
缓存清理要谨慎：别一删了之
composer clear-cache 会清掉整个缓存目录，包括所有已下载 ZIP 和已解析的 metadata（比如 packagist.org 的包列表）。下次任何操作都会重新拉全量数据。
- 真正需要清理的场景极少：比如怀疑缓存 ZIP 损坏（解压失败报校验错误）、或换源后旧 metadata 导致解析异常
- 更安全的做法是只删
cache/files/下特定包的 ZIP，留着cache/repo/（metadata）加速后续操作 - 定期清理建议用
composer cache-clean --all（Composer 2.2+），它按 LRU 自动淘汰旧包，不伤元数据
硬盘空间不是主要瓶颈，网络 IO 和解压开销才是真实成本——缓存 ZIP 文件本身是压缩态，解压比重新下载快得多，这点容易被忽略。
