根本原因是composer install默认按lock文件全量安装而非增量更新，且ci中缓存路径未持久化、key未绑定php版本等隐性依赖，导致缓存无法命中；必须同时缓存vendor和~/.composer/cache，并用--no-interaction --prefer-dist --optimize-autoloader参数组合才能实现高效复用。
为什么 composer install 在 CI 里总重下包，而不是增量更新？
根本不是网络或机器问题，而是默认行为就不支持“只更新变动部分”——composer install 本身不对比远程版本，它只按 composer.lock 下载已记录的包；所谓“增量更新”，实际只发生在 composer update 场景下，且必须配合缓存和元数据复用才有效。
常见错误现象：CI 中执行 composer update 却发现耗时暴涨，日志里反复出现 Downloading https://repo.packagist.org/packages.json —— 这说明它在重新拉取整个仓库元数据（约 15MB），而不是复用本地缓存。
-
composer update默认每次都会刷新packages.json元数据，除非加--locked或提前用composer install命中缓存 -
--prefer-dist必须启用，否则即使有缓存也走 git clone，绕过cache/files目录 - 私有包源配置变更（如 token、mirror URL）不会写入
composer.lock，但会强制刷新元数据，导致缓存失效
怎么让 CI 的 composer cache 命中率接近 100%？
关键不在“清不清缓存”，而在“缓存 key 是否精准绑定所有影响因素”。只用 hashFiles('**/composer.lock') 是最常见误判来源——它漏掉了 PHP 版本、扩展可用性、平台配置等隐性依赖。
GitHub Actions 示例中推荐的 key 是：${{ runner.os }}-php-${{ matrix.php-version }}-composer-${{ hashFiles('**/composer.lock') }}。这个组合能避免跨 PHP 版本复用缓存（比如 PHP 8.1 缓存被 PHP 8.2 加载，可能装错扩展兼容版）。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 缓存路径必须同时包含
vendor和~/.composer/cache，缺一不可；只缓存vendor会导致每次仍要下载解压 ZIP -
~/.composer/cache/files存的是 dist 包（zip/tar），~/.composer/cache/repo存的是元数据；两者都命中才算真正“免下载” - 若项目含
require-dev，而 CI 只跑测试，应明确加--no-dev，否则缓存 key 和实际安装内容不一致，导致后续构建 miss
哪些参数组合能让 composer install 真正跳过冗余操作？
不是加得越多越好，而是三个参数必须共存才能触发完整优化链：--no-interaction --prefer-dist --optimize-autoloader。漏掉任何一个，性能提升都会打折扣。
-
--no-interaction：跳过所有交互提示（如 license 确认），CI 必备 -
--prefer-dist：强制走 ZIP 安装路径，这是命中cache/files的前提；没它，哪怕缓存存在也走 source 模式 -
--optimize-autoloader：生成vendor/composer/autoload_classmap.php，减少 runtime 文件 stat，对测试启动速度敏感场景效果明显 - 额外建议加
--no-scripts：跳过post-install-cmd等钩子，容器里不需要执行权限修复、前端构建等操作
缓存过期和清理该怎么管？
别动不动就 composer clear-cache —— 它清的是整个缓存目录，包括你刚下载了一半的 zip，反而拖慢下次构建。真正该调的是缓存生命周期策略。
cache-files-ttl 控制 dist 包缓存有效期（默认 6 个月），cache-repo-ttl 控制元数据缓存有效期（同样默认 6 个月）。这两个值在 CI 场景下通常无需调低，除非你频繁切换私有源或镜像配置。
- 全局修改 ttl：
composer config -g cache-files-ttl 86400（设为 1 天） - 项目级覆盖：在
composer.json的config段加"cache-files-ttl": 3600 - 临时生效：
COMPOSER_CACHE_FILES_TTL=3600 composer install - 更安全的做法是用
composer clear-cache --gc：只清理过期或超限文件，保留有效缓存
最麻烦的其实是 require-dev 的混用问题——它们写在 composer.lock 里，但 CI 测试阶段才需要。如果缓存 key 没区分 --no-dev 和带 dev 的安装，很容易互相污染。这点容易被忽略，但直接影响命中率稳定性。
