必须缓存 ~/.composer/cache 而非 vendor/，因其存储与环境解耦的 ZIP 包和元数据，需显式设 COMPOSER_CACHE_DIR 并以 composer.lock 哈希为缓存 key。
用 Composer cache 目录加速 install
CI/CD 中每次 composer install 都重下包，本质是没复用已下载的 ZIP 或源码。Composer 自带缓存机制，默认存在 ~/.composer/cache，但 CI 环境通常无状态，缓存目录一跑完就丢。
实操上，得把缓存目录挂载为持久化路径或缓存层：
- GitHub Actions：用
actions/cache缓存~/.composer/cache，key 建议含composer.lock的 hash（如${{ hashFiles('**/composer.lock') }}） - GitLab CI：在
cache:下配key: $CI_COMMIT_REF_SLUG+paths: [ "$HOME/.composer/cache" ] - 自建 runner：确保
COMPOSER_CACHE_DIR指向共享卷，且权限允许写入
跳过 autoload 生成和脚本执行
composer install 默认会生成 autoload 文件、执行 post-install-cmd 脚本，这些在纯构建场景中往往多余，拖慢速度还可能因环境缺失失败。
加参数精简行为：
-
--no-autoloader：不生成vendor/autoload.php（后续由composer dump-autoload --classmap-authoritative替代） -
--no-scripts：跳过所有scripts（比如 Laravel 的php artisan optimize:clear） -
--no-progress：关闭进度条，减少输出干扰（尤其在日志体积敏感时）
典型命令：composer install --no-autoloader --no-scripts --no-progress
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
区分 dev 和 prod 环境依赖
CI 构建镜像或部署包时，通常不需要 require-dev 里的工具（如 PHPUnit、PHPStan），但默认 composer install 会装全量。
必须显式排除：
-
--no-dev是关键开关，它跳过require-dev并设COMPOSER_DEV_MODE=0 - 注意：如果
composer.lock是在 dev 环境生成的，--no-dev仍能正确读取 lock 文件里分离的依赖树 - 误用
--ignore-platform-reqs可能绕过 PHP 版本检查，导致线上运行时报错，除非你明确控制平台一致性
lock 文件变更检测要准，别瞎清缓存
缓存失效逻辑若只看分支名或时间戳，composer.lock 没变也重建缓存，等于白忙。反过来，lock 文件变了却没清缓存，又可能装错版本。
核心原则：
- 缓存 key 必须包含
composer.lock内容指纹（不是文件名或 commit id） - GitLab CI 示例：
key: "composer-${CI_COMMIT_REF_SLUG}-${CI_JOB_NAME}-$(sha256sum composer.lock | cut -d' ' -f1)" - GitHub Actions 不推荐用
hashFiles('composer.lock')后缀拼接，因该函数返回空字符串时会导致 key 冲突；稳妥做法是用hashFiles('**/composer.lock')并确保路径唯一
缓存本身不是银弹——如果项目用了 path repo 或 package 类型自定义包，它们不走缓存，得单独处理。
