composer 2.2+ 需用 repositories.packagist.org 而非 repo.packagist；项目级 repositories 字段优先级最高，会覆盖全局配置；换源后须清缓存、验证 url 斜杠及日志下载地址。

composer config -g repo.packagist 为什么没生效

不是命令写错了，而是 Composer 版本和配置优先级在“背刺”你。Composer 2.2+ 已转向 repositories.packagist.org 这个键名，继续用旧的 repo.packagist 可能被静默忽略——尤其在 CI 环境或新版 Docker 镜像里，根本不会报错，但 composer install 依然慢如官方源。

• 查当前生效的键：运行 composer config -g repositories.packagist.org，有输出才是真写进去了；空或报错说明你还在用老写法
• Windows 用户注意：COMPOSER_HOME 可能没生效，实际读的是 %APPDATA%\Composer\config.json，别在 Git Bash 里改完就去 CMD 验证
• 项目根目录下 composer.json 里只要存在 "repositories" 字段（哪怕只写了 {} 或 {"packagist.org": false}），全局配置就完全失效

换源后 composer install 还是卡在 packagist.org

大概率是缓存没清，或者 dist 包没走镜像——元数据从阿里云拉了，zip 却仍从 GitHub 或官方源下，网络差时直接超时。

• 必须执行：composer clear-cache，否则本地索引还是指向旧地址
• 验证是否真走镜像：composer update -vvv，盯住日志里 Downloading http:// 开头的 URL，得是 mirrors.aliyun.com 或对应镜像域名
• 某些模板（如 Laravel 脚手架）自带 "dist-url" 字段，会强制覆盖镜像的 dist 映射，删掉它再试

临时切源不污染环境的三种安全方式

不想改全局？比如帮同事调试、CI 脚本、或只初始化一次项目，硬编码配置反而容易留坑。

Workflow Decomposer

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

下载

• 单次命令指定：composer create-project laravel/laravel myapp --repository-url=https://mirrors.aliyun.com/composer/
• 仅当前项目生效（不写进 composer.json）：composer config repo.packagist composer https://mirrors.ustc.edu.cn/composer/（注意没 -g）
• CI 推荐腾讯云源：composer config -g repositories.packagist.org '{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}'，它默认 fallback 到官方源，避免因镜像同步延迟导致构建失败

URL 结尾少个 / 就 404

所有国内镜像源地址末尾必须带斜杠，这是 Composer 2.5+ 的硬性校验。漏掉就拼出错误路径，比如 https://mirrors.aliyun.com/composer/packages.json 会变成 https://mirrors.aliyun.com/composerpackages.json，直接 404。

• ✅ 正确：https://mirrors.aliyun.com/composer/
• ❌ 错误：https://mirrors.aliyun.com/composer（没斜杠）或 https://mirrors.aliyun.com/composer//（双斜杠）
• 华为云、腾讯云、中科大镜像都严格校验这个，阿里云虽宽松，但统一加斜杠最省心

最容易被跳过的其实是项目级 repositories 字段——它优先级最高，哪怕你全局配得再完美，只要项目里有这一行，就等于白干。换源后第一件事不是跑 install，而是 grep -i repositories composer.json。