composer在ci中变慢主因是默认不复用缓存且频繁请求远程元数据；应固定composer_cache_dir路径、启用--prefer-dist --no-progress --optimize-autoloader，并避免直接缓存vendor/。

Composer install 为什么在 CI 里总变慢？ 因为默认每次都会重新下载所有包、解压、安装、生成 autoloader，而 CI 环境通常不保留 vendor/ 和 composer.lock 的复用上下文。更关键的是：Composer 本身会检查远程仓库元数据（如 packagist.org），即使 lock 文件没变，composer install 仍可能触发大量 HTTP 请求。

• 默认不启用本地缓存目录（COMPOSER_CACHE_DIR 未设时走系统临时路径，CI 容器一销毁就丢）
• composer install --no-interaction --prefer-dist 是基础，但不够——--prefer-dist 只影响“选 tarball 还是 git clone”，不跳过元数据刷新
• GitHub Actions、GitLab CI 等默认禁用 HTTP 缓存头，Packagist 响应不被代理缓存

怎么让 Composer 在 CI 中真正复用缓存？ 核心是两件事：固定缓存路径 + 显式跳过元数据更新。不是靠「运气」或「加个 cache 步骤」就行。

• 在 CI 脚本开头设置：export COMPOSER_CACHE_DIR=/tmp/composer-cache（路径需可写且跨 job 持久化）
• 必须用 composer install --no-interaction --prefer-dist --no-progress --optimize-autoloader
  （--no-progress 减少输出开销；--optimize-autoloader 避免 runtime 时重复扫描）
• 最关键一步：加 --ignore-platform-reqs 仅当必要；但更推荐用 composer install --dry-run 预检，避免因 PHP 扩展缺失导致缓存失效后全量重装
• GitLab CI 示例缓存声明：cache: key: "$CI_COMMIT_REF_SLUG-composer" paths: ["/tmp/composer-cache"]

vendor 目录能直接缓存吗？风险在哪？ 能，但高风险——尤其当 composer.lock 变更、PHP 版本升级、或平台扩展要求变化时，缓存的 vendor/ 会静默失效，导致测试通过但线上报错。

• 直接缓存 vendor/ 看似快，实则绕过 Composer 的完整性校验（如 hash 校验、autoload 生成逻辑）
• 不同 PHP minor 版本（如 8.2.12 → 8.2.15）可能导致 opcache 或扩展行为差异，vendor/ 二进制兼容性无保障
• 更安全的做法：只缓存 COMPOSER_CACHE_DIR（含 dist 包、metadata、installed.json），每次 install 仍从缓存中重建 vendor/ —— 既快又稳

私有包和 GitHub Token 怎么不影响缓存命中？ 私有仓库（如 GitHub private repo）若用 git@ 方式声明，每次 clone 会生成不同 commit ref（因 shallow clone depth 或 ref 变动），导致缓存 miss；Token 若硬编码进命令行，还可能泄露或触发 rate limit。

• 私有包统一改用 https:// 协议 + auth.json（内容：{"github-oauth": {"github.com": "xxx"}}），并把 auth.json 放入缓存 key 计算范围
• 不要用 composer config github-oauth.github.com $TOKEN 动态写入，它会修改全局 config，污染缓存一致性
• 推荐方式：CI 中挂载 auth.json 到 $COMPOSER_HOME/auth.json，并确保该路径不在缓存排除列表里

缓存生效的前提是 lock 文件稳定、PHP 环境标识明确、认证方式可复现——漏掉其中任何一个，CI 就会退化成裸装模式。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载