镜像源配置必须配合缓存清理才生效，因Composer优先复用本地~/.composer/cache/files/中已有包文件，即使URL已切换镜像，旧缓存仍导致不走新源；执行composer clear-cache是强制步骤。
镜像源配置必须配合缓存清理才生效
换镜像源后 composer install 仍从 packagist.org 下载，不是镜像没配对，而是旧缓存还在。Composer 会优先复用 ~/.composer/cache/files/ 里已有的包文件，哪怕 URL 已切到阿里云镜像，只要缓存里有对应版本的 zip，它就直接解压——而这个 zip 很可能是早先从官方源下载的，校验通过后不触发重拉，但日志里看不到镜像域名，误以为“没走镜像”。
- 执行
composer clear-cache是切换镜像后的强制步骤，不是可选项 - 若项目级
composer.json中定义了repositories，会覆盖全局repo.packagist配置，此时需同步修改或删掉项目配置 - 验证是否真走镜像：加
-vvv运行composer install，重点看Downloading行末尾的 URL 域名，应为mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn
大包吞吐瓶颈不在网络带宽，而在缓存层级错位
下载单个 50MB+ 的 dist 包（如 Laravel、Symfony 官方包）慢，通常不是因为镜像 CDN 不够快，而是 Composer 没走 files 缓存层，被迫退回到 VCS 克隆或重复解压。关键判断点是 ~/.composer/cache/files/ 目录下是否有对应包的 zip 文件，以及其 mtime 是否合理。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 默认
cache-files-ttl是 180 天，但若磁盘空间不足（cache-files-maxsize默认 300MB），GC 会清掉旧文件；大包项目建议设为1024M -
--prefer-dist必须显式启用，否则 Composer 可能 fallback 到--prefer-source，绕过所有 dist 缓存 - 私有包若未预置 auth token，即使缓存存在，也会因认证失败跳过缓存，重新发起带 auth 的请求——此时
strace -e trace=openat,connect会显示连海外 IP
CI 环境中缓存 key 错配等于没缓存
GitLab CI 或 GitHub Actions 里写 cache: paths: [vendor/]，却不缓存 $COMPOSER_HOME/cache/，等同于只存了“结果”没存“原料”。下次 job 启动时，vendor/ 被恢复，但 ~/.composer/cache/files/ 是空的，composer install 仍要重下所有 zip。
- 必须同时缓存两个路径：
vendor/和$COMPOSER_HOME/cache/（GitLab）或~/.composer/cache/（GitHub Actions） - key 不能只用分支名：
${CI_COMMIT_REF_SLUG}在 merge request 流水线中可能重复；推荐用${CI_COMMIT_REF_SLUG}-$(sha256sum composer.lock | cut -d' ' -f1) - 不要在 CI 中运行
composer self-update：它会更新二进制和配置文件，导致缓存哈希失效
多级缓存不是自动协同，得靠 lock 文件对齐
composer.lock 里记录的 dist.url 字段决定实际下载地址。如果全局切了阿里云镜像，但 lock 文件里仍是 "https://api.github.com/repos/xxx/zipball/..."，Composer 会在校验 SHA256 前尝试从该 URL 下载——这一步可能失败或 fallback，最终仍走镜像，但过程多一次失败请求，拖慢吞吐。
- 换镜像后首次
composer install应加--no-cache，强制重生成 lock 文件中的 dist URL - 团队协作时，
composer.lock必须提交，且所有人用相同 Composer 版本（2.x 为底线），否则 lock 格式不兼容会触发全量 resolve - 若发现
composer show -p显示源地址正确，但strace仍连 GitHub API，大概率是 lock 文件残留旧 dist URL，删 lock + vendor 重建最干脆
files 缓存不会主动通知元数据缓存刷新，VCS 缓存也不会共享给 dist 下载路径。一个环节断开，整条链就降速——尤其是大包场景，错失 files 层意味着每次都要解压百 MB zip，磁盘 I/O 成硬瓶颈。 
