Composer换源必须严格配置三处：键名repo.packagist（非repos）、type值composer、URL为HTTPS且末尾带/；优先使用项目级配置并清缓存验证，否则静默失效。
composer config -g repo.packagist 命令必须写对三处
配错一个字符，Composer 就当没这回事——不报错、不提示、照连 packagist.org。最常踩的坑是：repo.packagist 写成 repos.packagist（多一个 s），composer 这个 type 值漏掉，或者 URL 少了末尾斜杠 /。
正确命令只有一条：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
-
repo.packagist是唯一合法键名，拼错就静默失效 - 中间的
composer是 type 值，缺了它 Composer 2.x 会 fallback 到默认源 - URL 必须 HTTPS + 末尾
/，否则路径拼接出错，返回 404
项目级配置比全局更可靠，尤其在 CI/CD 和团队协作中
全局配置容易被覆盖或权限干扰（比如宝塔面板用 www 用户执行，但你配的是 root 的 config）；项目级配置直接写进 composer.json，拉代码即生效，CI 构建时不用额外 setup。
进项目根目录后运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
- 该命令自动向
composer.json的repositories字段追加packagist条目，不覆盖已有私有源 - 如果项目已有
"repositories": {}，别手动编辑 JSON——格式错一个逗号就导致composer install报错 - 确认生效后，
composer.json中应出现类似："packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
换源后仍卡在 Downloading？先清缓存再重装
镜像只加速下载，但旧缓存里存着 packagist.org 的元数据，Composer 会优先读缓存并尝试从旧地址校验，结果就是卡在 DNS 或 TLS 握手——不是没走镜像，是根本没发请求过去。
- 必须执行：
composer clear-cache - 删掉
vendor/和composer.lock - 再跑：
composer install --no-cache（禁用缓存强制走新源）
别试图保留旧 composer.lock——它记录的是旧源的包哈希，和镜像返回的元数据不兼容，必然报 hash does not match。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
验证是否真走镜像，不能只看 config 输出
光跑 composer config -g repo.packagist 显示 URL 没用，得看到网络请求实际打到镜像域名才算数。
实测命令：
composer show monolog/monolog -vvv 2>&1 | grep "Downloading"
- 日志里必须出现
mirrors.aliyun.com或mirrors.cloud.tencent.com等镜像域名 - 如果看到
https://packagist.org或repo.packagist.org，说明 fallback 触发了，配置没起作用 - 注意：项目级配置优先级高于全局，
composer config --list和composer config --list --global要对比着看
镜像同步有延迟，新发布的包可能一小时内还没入库，别急着关 fallback；但若某个包长期找不到，先查镜像站首页的「最后更新时间」，再决定是否切源。
