CI中禁止定时执行composer update，因其会重算依赖图、绕过人工审查、触发未覆盖边界逻辑，导致测试通过但线上崩溃；升级应由人驱动、事件触发（如安全告警或PHP升级），并通过CI验证lock变更与平台兼容性。
不需要定期自动更新依赖，也不该由 CI 流水线主动执行 composer update。真正可控的依赖升级必须由人驱动、事件触发、CI 验证，且严格以 composer.lock 为校验锚点。
为什么 CI 中禁止定时跑 composer update
这是最常踩的坑：写个 cron 或 GitHub Actions schedule，每周自动 composer update 并 push lock —— 表面“自动化”，实则绕过审查、引入不可控变更。
-
composer update会重算整个依赖图，哪怕只升一个 patch 版本（如monolog/monolog:2.10.0 → 2.10.1），也可能触发未覆盖的边界逻辑，导致测试通过但线上Class not found - CI 通常启用
--no-scripts，post-update-cmd根本不执行，你写的钩子形同虚设 - 它无法感知安全告警（如
CVE-2026-1234）、PHP 版本变更或平台扩展缺失，纯属盲目升级 - 一旦自动提交新
composer.lock，就失去了版本变更的可追溯性和人工确认环节
升级动作该由什么触发？
可信的升级意图只能来自代码变更或外部事件，不是时间表。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 检测
composer.json修改：git diff --name-only HEAD~1 composer.json—— 这才是人明确想改依赖的信号 - 响应安全扫描结果：用
composer audit --format=json（Composer ≥2.5）提取含"severity": "critical"的包，优先处理guzzlehttp/guzzle、laravel/framework等高危项 - 适配 PHP 升级：当 CI 检测到 PHP 从 8.2 升至 8.3，运行
composer outdated --direct --ignore=php，再过滤掉不满足新require的包 - 禁止任何无参数的
composer update；批量升必须限定范围，例如：composer update symfony/console guzzlehttp/guzzle --with-dependencies
CI 流水线里真正该做的三件事
CI 不负责“选版本”，只负责“装对的版本”并确保它能跑通。
- 必须用
composer install，且前置校验：composer validate --strict（确认composer.json和composer.lock匹配）、composer check-platform-reqs（验证 PHP 版本、ext-zip等是否满足新依赖） - 安装命令必须带三个参数：
composer install --no-dev --optimize-autoloader --classmap-authoritative—— 漏一不可，否则 autoload 可能失效或性能崩塌 - 升级后必须检查
composer.lock是否变更：git diff --quiet composer.lock || echo "lock changed"，这是判断本次流水线是否真做了升级的唯一依据
缓存和内存设置这些细节不能省
看似边缘，但一错就卡住整个流水线。
- 缓存目标只能是
~/.composer/cache，绝不能是vendor/—— 后者混用不同 PHP 版本生成的 autoload 文件，会导致随机Cannot declare class - CI 环境默认内存常不足，
composer install直接被Killed；开头必须加：export COMPOSER_MEMORY_LIMIT=-1或export COMPOSER_MEMORY_LIMIT=2G - 私有包拉取失败？别往仓库里塞
auth.json，改用 CI 内置的 secrets 注入 token，或配置 SSH Agent（GitLab CI 用ssh-agent，GitHub Actions 用webfactory/ssh-agent）
依赖升级不是越勤越好，而是越准越好。最容易被忽略的是：所有升级操作都必须在 PR 中发起、经人工 review、由 CI 验证 lock 变更和平台兼容性——跳过其中任一环，所谓的“自动化”就只是把风险批量放大。
