直接缓存vendor/目录在CI中大概率出问题，因其易引发权限冲突、autoload不兼容及composer.lock更新后缓存未失效三类隐患；应优先复用$HOME/.composer/cache中与环境解耦的下载包缓存。
为什么缓存 vendor/ 目录在 CI 中大概率出问题
直接 cache 或 artifacts vendor/ 目录，表面看能跳过安装，实则埋下三类隐患：权限冲突（如 root 写的文件被 jenkins 用户读）、autoload 文件不兼容（PHP 版本或 ext-apcu 开关变化导致 Cannot declare class）、composer.lock 更新后缓存未失效仍被复用。这些错误往往只在部署后暴露，CI 阶段无法捕获。
真正安全可复用的是 Composer 下载层——它只存 .zip/.tar.gz 包和 dist hash，与 PHP 版本、扩展、用户身份完全解耦。该缓存位于 $HOME/.composer/cache，默认路径即 ~/.composer/cache。
- 每次
composer install --prefer-dist都会先查这个目录，命中则跳过网络下载 - 只要
composer.lock不变，包内容就确定，缓存可跨项目、跨构建复用 - CI 中只需确保该路径被一致挂载或缓存，无需干预 vendor 生成逻辑
如何让 Jenkins Pipeline 稳定复用 Composer 全局缓存
Jenkins 的关键不是“在 pipeline 里写 cache 指令”，而是让所有构建共享同一 COMPOSER_CACHE_DIR 路径。硬编码到 agent 启动环境最可靠。
- 在 agent 机器上（systemd service 或 Docker entrypoint）添加：
export COMPOSER_CACHE_DIR=/var/lib/jenkins/composer-cache - 执行：
sudo mkdir -p /var/lib/jenkins/composer-cache && sudo chown jenkins:jenkins /var/lib/jenkins/composer-cache - Pipeline 中无需额外命令，只要调用
php composer.phar install或/opt/composer/bin/composer install即自动生效 - 若用 Docker agent，必须映射：
args '-v /var/lib/jenkins/composer-cache:/home/jenkins/.composer/cache'
别在 pipeline 里用 sh 'composer config -g cache-dir ...' —— 这会写入临时配置，且可能因用户权限错位（如 sudo 执行但 runner 以 jenkins 身份运行）而失效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
GitLab CI 和 GitHub Actions 中缓存 key 怎么写才不翻车
缓存 key 必须绑定 composer.lock 哈希，否则 lock 更新后仍用旧缓存，依赖树就错了。仅靠分支名或 PHP 版本不够。
- GitHub Actions：
key: ${{ runner.os }}-php-${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }} - GitLab CI：
key: ${CI_COMMIT_REF_SLUG}-${PHP_VERSION}-composer-${CI_PIPELINE_IID}，但更稳妥是：key: ${CI_COMMIT_REF_SLUG}-composer-${sha256sum composer.lock | cut -d" " -f1}（需在 script 中计算） - 务必加
restore-keys（GH）或policy: push（GitLab），应对 PHP 小版本升级（8.2.1 → 8.2.3）等兼容变更
别把 composer.json 哈希单独当 key 主体——它可能含 config.platform 或 scripts 变更，但不影响依赖包内容；主 key 必须是 lock 文件哈希。
CI 中必须加的参数和校验项
composer install 在 CI 中不是“装完就行”，漏掉关键参数会导致 autoload 性能差、dev 包污染生产环境、甚至锁文件不一致。
- 必须用
composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative --no-interaction - 开头加
composer validate --strict，检查composer.json和composer.lock是否匹配，不匹配直接失败 - 禁止出现
composer update—— 它会重写 lock，CI 只负责还原，不负责决策 - 镜像源必须验证生效：
composer config -g repo.packagist输出必须是完整 JSON，且 URL 末尾有/，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
最常被忽略的是 --classmap-authoritative：没它，autoload 会反复试探文件是否存在，opcache 失效时容易漏类；有它，PHP 直接查 classmap，快且确定。
