缓存路径是决定composer install耗时的关键开关，它控制zip包下载解压校验，需存在可写且内容匹配dist.sha256；其下files/存包、repo/存元数据、vcs/存git副本，不涉及opcache或vendor目录。
缓存路径不是“可有可无的配置”，而是 Composer 能否跳过下载、解压、校验三步的关键开关。 它直接决定 composer install 是花 3 秒还是 3 分钟——前提是路径存在、可写、且内容匹配 composer.lock 中的 dist.sha256。
缓存路径管什么，不管什么
Composer 缓存路径（cache-dir）是顶层根目录，它下面固定包含三个子目录：
-
files/：存 ZIP/TAR 包，composer install --prefer-dist时直接解压这里的内容 -
repo/：存 Packagist 的元数据（如packages.json），影响Loading composer repositories阶段 -
vcs/：存 Git 克隆的仓库副本，只对"type": "vcs"或私有 Git 包生效
它不管 PHP OPcache、不缓存 vendor/ 目录本身、也不参与自动加载映射生成（那是 composer dump-autoload 干的事）。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么改缓存路径经常没效果
常见失效场景不是路径设错了，而是以下任意一条没满足：
-
COMPOSER_CACHE_DIR环境变量未设置，或被composer config --global cache-dir覆盖（前者优先级更高） - 路径指向的目录不存在，或当前用户无写权限（Docker 中 UID 不匹配会静默失败）
- 只改了
cache-dir，但没同步配cache-vcs-dir，导致 Git 包每次重 clone -
composer.lock文件被修改（哪怕只是空格增删），所有dist.sha256校验失败，缓存全部跳过
CI 场景下缓存路径怎么设才真生效
在 Docker 或 GitHub Actions 等 CI 环境中，必须显式挂载并指定路径，否则每次都是全新 ~/.composer/cache：
- Linux/macOS：用
docker run -e COMPOSER_CACHE_DIR=/cache -v $(pwd)/ci-cache:/cache - GitHub Actions：
COMPOSER_CACHE_DIR: ${{ github.workspace }}/composer-cache+actions/cache挂载该路径 - Windows CI：避免反斜杠，用
D:/composer-cache，别用D:\composer-cache - 务必加
cache-read-only: false（默认值），否则缓存无法写入，后续构建全失效
真正起作用的从来不是“有没有缓存路径”，而是“路径是否被进程真实访问到、写入成功、且内容未被意外清理”。composer install -vvv 日志里出现 Downloading ... 行数明显减少，才是缓存生效的唯一证据。
