ci中直接运行composer install可行但需加--no-interaction --no-progress --optimize-autoloader --ignore-platform-reqs参数，并必须缓存vendor目录，禁用composer update（除定时dry-run监控外），且须确保composer版本兼容。
CI/CD 中直接运行 composer install 是可行的，但默认行为极易导致构建不稳定——关键在于禁用交互、锁定依赖、跳过开发阶段，并确保缓存生效。
为什么 CI 环境下 composer install 会失败或变慢
本地开发时你可能习惯运行 composer update 或依赖未提交的 composer.lock，但在 CI 中：
• composer install 会报错：找不到 composer.lock（因为没提交）或锁文件与 composer.json 不一致
• 默认启用 --no-interaction 不够——它仍可能尝试访问 GitHub OAuth token 提示、执行 post-install scripts 中的交互命令
• 每次都重装全量 vendor 目录，无缓存时耗时常超 2 分钟
composer install 必须加的参数组合
在 CI 脚本中（如 GitHub Actions、GitLab CI）应固定使用以下调用：
composer install --no-interaction --no-progress --optimize-autoloader --ignore-platform-reqs
说明：
• --no-interaction：禁用所有用户输入（包括 token 请求、脚本确认等）
• --no-progress：避免进度条干扰日志解析，也略微提速
• --optimize-autoloader：生成扁平化 classmap，PHP 加载更快（尤其对无 OPCache 的 CI 容器重要）
• --ignore-platform-reqs：跳过 PHP 版本、扩展检查——CI 环境常为最小化镜像，不必强求和本地一致；若需严格校验，改用 --platform=php:8.2 显式声明
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
vendor 目录缓存不是可选项，而是必须项
不缓存 vendor/，每次构建都是从零下载+解压+安装，既慢又易受 Packagist 网络波动影响。实际配置要点：
• GitHub Actions：用 actions/cache@v4 缓存 vendor/，key 基于 composer.lock 的 hash（而非时间戳）
• GitLab CI：用 cache: + key: ${CI_COMMIT_REF_SLUG}-composer 不够稳，应改用 key: composer-${CI_COMMIT_SHA} 或基于 lock 文件内容生成的哈希
• 注意：缓存前确保 composer install 已成功执行一次，且不要缓存 composer.phar 自身（它体积小、更新频次低，反而容易因版本不一致引发问题）
CI 中要不要跑 composer update？
绝大多数场景下不要。理由很实在：
• composer update 会修改 composer.lock，而 CI 不该产生代码变更
• 若真需升依赖（如安全修复），应由人触发专用流水线（如 PR 标记 update-deps），并在合并前人工审核 lock 变更
• 唯一例外：每日定时 job 执行 composer update --dry-run 并报告差异，用于监控过期依赖——但它不写入任何文件
最易被忽略的一点：CI 镜像里如果预装了旧版 Composer（如 v1），而项目用了 PHP 8.2+ 的插件或新语法，composer install 会静默失败或降级兼容。务必在 CI 步骤开头显式检查并升级：composer --version 和必要时 curl -sS https://getcomposer.org/installer | php -- --install-dir=/usr/local/bin --filename=composer。
