composer install慢主因是未缓存~/.composer/cache目录，即使配置国内镜像，zip包仍需重下重解；必须同时缓存该目录与vendor/，并配合--prefer-dist等参数才能生效。
缓存 Composer 国内镜像包本身没意义，真正要缓存的是 ~/.composer/cache —— 它存的是从镜像下载下来的 ZIP 包和元数据，不是镜像源配置。
为什么改了镜像源后 install 还慢？
常见现象：在 before_script 里执行了 composer config -g repo.packagist https://mirrors.aliyun.com/composer/，但 composer install 日志里仍看到大量 Downloading xxx.zip，耗时没降。
- 根本原因不是镜像没切对，而是
~/.composer/cache没被缓存，每次作业都清空——哪怕走的是阿里云镜像，ZIP 包也得重下、重解、重校验 -
composer config -g写入的是全局配置，但 CI runner 用户（如gitlab-runner）的$HOME和 root 不同，sudo composer config -g很可能写进了错误用户家目录 - 验证是否真走镜像：加
-vvv运行composer install，日志里必须出现GET https://mirrors.aliyun.com/composer/p2/...才算生效
缓存 ~/.composer/cache 的正确姿势
只缓存这个路径，不缓存 vendor/；它与 PHP 版本、OS、扩展无关，只跟 composer.lock 哈希绑定，安全且复用率高。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 显式设置缓存目录：在 job 开头加
export COMPOSER_CACHE_DIR="$HOME/.composer-cache-$PHP_VERSION"，避免多 PHP 版本混用 - GitLab CI 中
cache.paths必须写两行：vendor/和$HOME/.composer-cache-$PHP_VERSION—— 缺一不可，只写后者，vendor/每次重建；只写前者，缓存无效 - GitHub Actions 推荐用
actions/cache@v4，path填~/.composer/cache，key用${{ hashFiles('**/composer.lock') }}，别用分支名硬编码
composer install 必带的参数组合
漏掉任何一个，缓存基本白搭，尤其 --prefer-dist 是触发缓存 ZIP 包的关键开关。
-
--no-interaction：跳过交互，CI 必备 -
--prefer-dist：强制走 ZIP 包安装（比 git clone 快 3–5 倍），只有它才能读~/.composer/cache里的 dist 缓存；没它，哪怕 cache-dir 存在，也会 fallback 到 source -
--optimize-autoloader：生成扁平化 autoload_classmap.php，加载类快 20%+ -
--no-dev：CI 环境通常不需要 dev 依赖，漏掉它会让安装变慢、缓存体积膨胀
容易被忽略的兼容性陷阱
缓存能命中，不代表 vendor 能直接用。很多团队卡在这一步，以为缓存生效了，结果跑测试报 Class not found。
-
composer.lock必须被git add并提交，否则composer install会退化为update，重新解析依赖树，缓存失效 - 私有包认证不能靠
auth.json文件硬编码，要用 CI 变量COMPOSER_AUTH注入 JSON 字符串，否则缓存因认证失败中断 - 不同 PHP 版本生成的
vendor/autoload.php不兼容，所以vendor/缓存必须按$PHP_VERSION分 key，或干脆不缓存它，只靠~/.composer/cache+install重建
