ci/cd中必须用composer install而非update，因install严格按已提交的composer.lock复现依赖，确保构建一致性；update会重算依赖、破坏可重现性。
CI/CD里用composer update等于主动放弃构建一致性——必须用composer install，且composer.lock必须已提交、校验通过、缓存正确。
为什么composer install在CI里总卡住或失败
不是命令写错了，而是环境没对齐：
-
composer.lock没提交到 Git：CI 从空目录启动，composer install直接报错退出，不会自动生成 lock - PHP 版本不匹配：
composer.json中"php": "^8.1"，但 CI 使用的是 PHP 8.0，部分包会被跳过或解析失败 - 缺失关键扩展：Alpine 镜像默认不带
ext-zip或ext-pdo，composer install会静默失败（无错误输出，进程被 kill） - 内存不足：CI 默认限制 PHP 内存，
composer install加载依赖图时峰值高，报Killed或Allowed memory size exhausted
解决方法：开头加 export COMPOSER_MEMORY_LIMIT=-1，并确保基础镜像已装好 zip、openssl 等扩展。
composer install该加哪些参数才适合CI环境
不是“能跑就行”，而是要兼顾安全、性能和可重现性：
-
--no-dev：生产部署必须加，避免装入phpunit、phpstan等非运行时依赖 -
--optimize-autoloader：把 PSR-4 映射编译成静态数组，减少每次 autoload 的file_exists()调用 -
--classmap-authoritative：告诉 autoloader “不在 classmap 里的类，一律不存在”，彻底跳过文件系统探测 -
--no-interaction --no-progress：防止交互式提示卡住流水线
注意：--classmap-authoritative 必须与 --no-dev 同时使用；否则代码中若存在 class_exists('PHPUnit\Framework\TestCase') 这类判断，会直接 fatal。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
缓存vendor/还是~/.composer/cache？
缓存 vendor/ 是常见误区，它会导致随机 autoload 失败：
-
vendor/包含环境敏感内容：不同 PHP 版本生成的autoload_static.php不兼容；opcache或apcu编译产物混用会引发Cannot declare class -
~/.composer/cache只存 zip/dist 包和元数据，与 PHP 版本、扩展、OS 完全解耦，是唯一安全缓存目标 - GitHub Actions 示例 key 必须含
${{ hashFiles('**/composer.lock') }}，否则 lock 更新后缓存不失效
GitLab CI 中写 cache: paths: [~/.composer/cache]，别写 vendor/ ——哪怕你看到 vendor 目录变大了，也不代表它该进缓存。
怎么让 CI 真正验证composer.lock是否最新
光有 lock 文件不够，得验证它和 composer.json 是否同步：
- CI 开头加
composer validate --strict：检查 JSON 格式、字段合法性、lock 与 json 是否匹配 - 本地 pre-commit 钩子加
composer install --dry-run：提前发现 lock 过期，避免提交后 CI 报错 - CI 构建完可选做一次轻量校验：
rm -rf vendor && composer install --no-dev --dry-run，确认无变更输出
最危险的情况是：lock 文件被本地手动生成但未提交，CI 缓存 key 匹配失败，每次冷安装还误以为“只是慢一点”——其实已经失去可重现性底线。
