Composer在CI中变慢主因是默认不复用缓存且频繁请求远程元数据；应固定COMPOSER_CACHE_DIR路径、启用--prefer-dist --no-progress --optimize-autoloader，并避免直接缓存vendor/。
Composer install 为什么在 CI 里总变慢？
因为默认每次都会重新下载所有包、解压、安装、生成 autoloader，而 CI 环境通常不保留 vendor/ 和 composer.lock 的复用上下文。更关键的是：Composer 本身会检查远程仓库元数据（如 packagist.org），即使 lock 文件没变，composer install 仍可能触发大量 HTTP 请求。
- 默认不启用本地缓存目录（
COMPOSER_CACHE_DIR 未设时走系统临时路径，CI 容器一销毁就丢）
-
composer install --no-interaction --prefer-dist 是基础，但不够——--prefer-dist 只影响“选 tarball 还是 git clone”，不跳过元数据刷新
- GitHub Actions、GitLab CI 等默认禁用 HTTP 缓存头，Packagist 响应不被代理缓存
怎么让 Composer 在 CI 中真正复用缓存？
核心是两件事：固定缓存路径 + 显式跳过元数据更新。不是靠「运气」或「加个 cache 步骤」就行。
- 在 CI 脚本开头设置：
export COMPOSER_CACHE_DIR=/tmp/composer-cache（路径需可写且跨 job 持久化）
- 必须用
composer install --no-interaction --prefer-dist --no-progress --optimize-autoloader
（--no-progress 减少输出开销；--optimize-autoloader 避免 runtime 时重复扫描）
-
最关键一步：加
--ignore-platform-reqs 仅当必要；但更推荐用 composer install --dry-run 预检，避免因 PHP 扩展缺失导致缓存失效后全量重装
- GitLab CI 示例缓存声明：
cache: key: "$CI_COMMIT_REF_SLUG-composer" paths: ["/tmp/composer-cache"]
vendor 目录能直接缓存吗？风险在哪？
能，但高风险——尤其当 composer.lock 变更、PHP 版本升级、或平台扩展要求变化时，缓存的 vendor/ 会静默失效，导致测试通过但线上报错。
- 直接缓存
vendor/ 看似快，实则绕过 Composer 的完整性校验（如 hash 校验、autoload 生成逻辑）
- 不同 PHP minor 版本（如 8.2.12 → 8.2.15）可能导致 opcache 或扩展行为差异，
vendor/ 二进制兼容性无保障
- 更安全的做法：只缓存
COMPOSER_CACHE_DIR（含 dist 包、metadata、installed.json），每次 install 仍从缓存中重建 vendor/ —— 既快又稳
私有包和 GitHub Token 怎么不影响缓存命中？
私有仓库（如 GitHub private repo）若用 git@ 方式声明，每次 clone 会生成不同 commit ref（因 shallow clone depth 或 ref 变动），导致缓存 miss；Token 若硬编码进命令行，还可能泄露或触发 rate limit。
- 私有包统一改用
https:// 协议 + auth.json（内容：{"github-oauth": {"github.com": "xxx"}}），并把 auth.json 放入缓存 key 计算范围
- 不要用
composer config github-oauth.github.com $TOKEN 动态写入，它会修改全局 config，污染缓存一致性
- 推荐方式：CI 中挂载
auth.json 到 $COMPOSER_HOME/auth.json，并确保该路径不在缓存排除列表里
COMPOSER_CACHE_DIR 未设时走系统临时路径，CI 容器一销毁就丢）composer install --no-interaction --prefer-dist 是基础，但不够——--prefer-dist 只影响“选 tarball 还是 git clone”，不跳过元数据刷新- 在 CI 脚本开头设置：
export COMPOSER_CACHE_DIR=/tmp/composer-cache（路径需可写且跨 job 持久化） - 必须用
composer install --no-interaction --prefer-dist --no-progress --optimize-autoloader
（--no-progress减少输出开销；--optimize-autoloader避免 runtime 时重复扫描） -
最关键一步：加
--ignore-platform-reqs仅当必要；但更推荐用composer install --dry-run预检，避免因 PHP 扩展缺失导致缓存失效后全量重装 - GitLab CI 示例缓存声明：
cache: key: "$CI_COMMIT_REF_SLUG-composer" paths: ["/tmp/composer-cache"]
vendor 目录能直接缓存吗？风险在哪？
能，但高风险——尤其当 composer.lock 变更、PHP 版本升级、或平台扩展要求变化时，缓存的 vendor/ 会静默失效，导致测试通过但线上报错。
- 直接缓存
vendor/ 看似快，实则绕过 Composer 的完整性校验（如 hash 校验、autoload 生成逻辑）
- 不同 PHP minor 版本（如 8.2.12 → 8.2.15）可能导致 opcache 或扩展行为差异，
vendor/ 二进制兼容性无保障
- 更安全的做法：只缓存
COMPOSER_CACHE_DIR（含 dist 包、metadata、installed.json），每次 install 仍从缓存中重建 vendor/ —— 既快又稳
私有包和 GitHub Token 怎么不影响缓存命中？
私有仓库（如 GitHub private repo）若用 git@ 方式声明，每次 clone 会生成不同 commit ref（因 shallow clone depth 或 ref 变动），导致缓存 miss；Token 若硬编码进命令行，还可能泄露或触发 rate limit。
- 私有包统一改用
https:// 协议 + auth.json（内容：{"github-oauth": {"github.com": "xxx"}}），并把 auth.json 放入缓存 key 计算范围
- 不要用
composer config github-oauth.github.com $TOKEN 动态写入，它会修改全局 config，污染缓存一致性
- 推荐方式：CI 中挂载
auth.json 到 $COMPOSER_HOME/auth.json，并确保该路径不在缓存排除列表里
vendor/ 看似快，实则绕过 Composer 的完整性校验（如 hash 校验、autoload 生成逻辑）vendor/ 二进制兼容性无保障COMPOSER_CACHE_DIR（含 dist 包、metadata、installed.json），每次 install 仍从缓存中重建 vendor/ —— 既快又稳git@ 方式声明，每次 clone 会生成不同 commit ref（因 shallow clone depth 或 ref 变动），导致缓存 miss；Token 若硬编码进命令行，还可能泄露或触发 rate limit。
- 私有包统一改用
https://协议 +auth.json（内容：{"github-oauth": {"github.com": "xxx"}}），并把auth.json放入缓存 key 计算范围 - 不要用
composer config github-oauth.github.com $TOKEN动态写入，它会修改全局 config，污染缓存一致性 - 推荐方式：CI 中挂载
auth.json到$COMPOSER_HOME/auth.json，并确保该路径不在缓存排除列表里
缓存生效的前提是 lock 文件稳定、PHP 环境标识明确、认证方式可复现——漏掉其中任何一个，CI 就会退化成裸装模式。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
