CI/CD 中应使用 composer install --no-dev --no-interaction --optimize-autoloader 安装生产依赖，缓存 vendor 和 ~/.composer/cache，禁止在 CI 中运行 update 或 dump-autoload，校验 composer.json 和 lock 文件一致性，并用 validate 与 audit 保障安全。
在 CI/CD 流程中正确使用 Composer，核心是避免重复下载、确保依赖一致性、防止构建污染，并兼顾安全与效率。关键不是“每次都跑 install”，而是按需、分层、可复现地管理依赖。
区分开发与生产环境依赖
CI 环境通常只需运行时依赖（require），不需要开发依赖（require-dev）。除非要执行测试或代码质量检查，否则应跳过它们以加快构建、减小镜像体积。
- 生产构建用：
composer install --no-dev --no-interaction --optimize-autoloader - 测试阶段才加
--with-all-dependencies或显式启用require-dev - 检查
composer.json和composer.lock是否同时提交——CI 必须基于 lock 文件安装，否则无法保证版本一致
缓存 Composer 的 vendor 目录和下载包
每次从零下载所有包既慢又不稳定。主流 CI 平台（GitHub Actions、GitLab CI、CircleCI）都支持路径级缓存，应优先缓存：
-
vendor/目录（注意：仅当composer.lock未变时才复用） -
~/.composer/cache/（Composer 自带的包缓存，加速install和update） - GitHub Actions 示例：
actions/cache@v3按composer.lock哈希做 key 缓存 vendor
避免在 CI 中运行 update 或 dump-autoload
composer update 会修改 composer.lock，这不该发生在自动化构建中——它属于开发决策，应由人触发并走 PR 流程。同理，dump-autoload 一般也不必单独跑，因为 install 已默认生成优化后的 autoloader。
- CI 脚本里禁止出现
composer update（除非是专门的“更新依赖”流水线） - 如需重生成 autoload（例如切换 PSR-4 映射），应在本地运行并提交变更，CI 只负责验证
- 若用 Docker 构建，确保
composer install在构建层执行，而非容器启动时
校验完整性与安全性
CI 是拦截问题的第一道防线，可在安装后快速验证依赖健康度：
- 运行
composer validate --strict检查composer.json格式与字段合规性 - 用
composer audit（Composer 2.5+）扫描已知漏洞（需联网，建议设超时） - 对私有包，确认
auth.json不硬编码在仓库中；改用 CI 环境变量注入凭证
基本上就这些。不复杂但容易忽略的是：始终让 CI 信任 lock 文件、不碰 update、缓存要带语义化 key、安全检查别流于形式。
