换镜像源必须先执行 composer clear-cache，否则旧缓存仍拉取 packagist.org 元数据，导致“resolving dependencies”卡顿或 hash 不匹配；镜像仅加速下载，不优化本地依赖求解。

换镜像源不能跳过 composer clear-cache，否则旧缓存会继续拉取 packagist.org 的元数据，升级过程卡在 “Resolving dependencies” 或反复报 hash does not match。

为什么 composer update 换了镜像还是慢

镜像只加速包下载，不解决本地依赖求解卡顿。“Resolving dependencies” 阶段完全离线，Composer 在本地穷举满足所有版本约束的组合。尤其当你用了 "*"、"^1.0 || ^2.0" 或 "minimum-stability": "dev"，求解器可能指数级爆炸。

• 先确认是否真走镜像：执行 composer update -vvv，看日志里请求的域名是不是 mirrors.aliyun.com 或其他国内地址；如果还出现 packagist.org，说明镜像根本没生效
• 检查 composer.json 里有没有手动写的 "repositories" 字段——它会覆盖全局配置；运行 composer config --list 和 composer config --list --global 对比实际生效项
• 删掉 vendor/ 和 composer.lock 后再跑 composer install，比盲目 update 更快更稳（尤其框架升级时）

composer config -g repo.packagist 命令总静默失效

90% 的失败源于三个硬性条件漏一个：repo.packagist 键名写错（比如 repos.packagist 多个 s）、漏掉中间的 composer type 值、URL 末尾没斜杠。

Workflow Decomposer

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

下载

• 正确命令必须是：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 验证是否写入：composer config -g repo.packagist 输出应为完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或仍是 https://packagist.org 就说明没成功
• Windows 用户注意路径在 C:\Users\用户名\AppData\Roaming\Composer\config.json，别手写，一律用命令写入

宝塔或 CI 环境里全局配置不起作用

宝塔「一键部署」、PHP 管理器、GitHub Actions runner 默认以 www 或非 root 用户运行，读不到你 root 下的 /root/.composer/config.json。

• 查实际执行用户：whoami 或看宝塔任务日志 UID
• 给对应用户重配：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• CI 脚本中别依赖全局配置，改用临时参数更可靠：composer update --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/

框架升级最常踩的坑不是镜像没配对，而是 composer.lock 没清、缓存没清、用户权限没对齐——三者任一出问题，update 就会回到“下载卡住→报错→重试→再卡住”的死循环。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！