GitLab CI 中 vendor 目录每次重装是因为 runner 环境干净、composer.lock 未提交、PHP 扩展缺失；应提交 lock 文件、使用含完整扩展的 CI 镜像、配置 composer 全局缓存与 vendor 路径缓存，并确保 PHP 版本严格一致。
GitLab CI 里 vendor 目录为什么每次都在重装？
因为默认情况下，composer install 每次都在干净的 runner 环境里跑，vendor/ 不保留、composer.lock 可能没提交、甚至 PHP 扩展都没装全。结果就是：5 分钟构建，4 分钟在装包。
- 确认
composer.lock已提交到仓库（没它，install会退化成update） - CI 镜像必须含 PHP + 常用扩展（如
mbstring、xml、zip），否则composer install直接报错退出 - 别在
.gitlab-ci.yml里写composer create-project或require—— 这类命令会改锁文件，破坏可重现性
怎么配 cache 让 vendor 真正复用？
GitLab 的 cache 机制不直接缓存 vendor/（路径含斜杠易冲突），而是缓存 Composer 的全局 vendor 和下载包缓存（~/.composer/cache），再配合 --no-interaction --prefer-dist --optimize-autoloader 提速。
- 用
key: "$CI_JOB_NAME-$CI_COMMIT_REF_SLUG"区分分支和作业，避免 dev 分支缓存污染 main - 必须加
paths:显式声明缓存路径：- ~/.composer/cache（下载包）、- vendor/（可选，但需确保 lock 文件一致） - 如果项目用了 private package（如 GitLab 私有库），得在 job 里提前注入
auth.json，否则缓存命中后仍会卡在认证环节
PHP 版本和扩展不匹配导致 composer install 失败
错误常表现为：Your requirements could not be resolved to an installable set of packages. 或更隐蔽的 Class 'Foo' not found —— 实际是某个包因 PHP 版本太高/太低被跳过安装。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- CI 镜像 PHP 版本必须和本地开发、生产环境严格一致（比如都用
php:8.2-cli，别混用php:8.2和php:8.2-apache） - 检查
composer.json中的"platform"配置：它会欺骗 Composer “假装”有某版本 PHP 或扩展，但 CI 环境真没装，运行时就崩 - 推荐删掉
"platform"，改用composer show php和php -m在 CI job 开头验证实际环境
vendor 缓存失效却没报错，怎么快速定位？
GitLab UI 上显示 “Cache loaded” 不代表 vendor 有效复用 —— 可能只是缓存了空目录，或用了旧 lock 文件。
- 在
composer install后加一行：ls -la vendor/autoload.php && composer dump-autoload -o，确认文件存在且 autoloader 可生成 - 开启 Composer 详细日志：
COMPOSER_MEMORY_LIMIT=-1 composer install -v，看是否真从 cache 下载 dist 包（输出含Downloading ... from cache） - CI 日志里搜
Writing lock file：出现说明 lock 被重写，缓存已失效；没出现且没报错，才大概率复用了
最常被忽略的是：不同 PHP 小版本（如 8.2.12 vs 8.2.15）可能触发 Composer 自动升级自身，导致缓存 hash 变化 —— 这种问题不会报错，但 vendor 重建，得盯紧 runner 镜像 tag 是否固定。
