正确，必须同时满足三个硬条件：键名repo.packagist（单数）、中间显式指定composer类型值、URL为HTTPS且末尾带斜杠；漏一即静默失效，需执行composer clear-cache并验证输出为完整JSON对象。
composer config -g repo.packagist 命令写对了吗
这条命令极易静默失败，不报错也不提示，但实际根本没生效。必须同时满足三个硬条件：
• repo.packagist 不能写成 repos.packagist（多一个 s 就被忽略）
• 中间必须带 composer 这个 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ ✅，漏掉 composer 就 fallback 到官方源 ❌
• URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（少斜杠会 404）
换镜像后为什么 composer install 还是慢
最常被跳过的一步：composer clear-cache 没执行。缓存里还存着旧的 packages.json 和元数据，Composer 会优先读缓存，哪怕配置已改，它仍试图从旧地址拉校验信息，结果卡在 DNS 解析或 TLS 握手。
其他关键干扰项：
• 项目级 composer.json 中存在 repositories 字段，会直接覆盖全局配置
• 宝塔、CI 或计划任务以 www 用户运行，但 composer config -g 写的是 root 配置（路径为 /root/.composer/config.json），www 根本读不到；应切到对应用户下执行：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
• 用了过时插件如 hirak/prestissimo，它在 Composer 2.2+ 中不仅无效，还会干扰原生并发下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
怎么确认当前走的是哪个镜像源
运行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。空、null、仍是 https://packagist.org 都说明没写进去。
更可靠的验证方式是加 -vvv：运行 composer install -vvv，看日志中是否出现类似 Reading packages.json from cache at /home/user/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json 的路径 —— 出现镜像域名才算真正生效。
如果日志里还有 https://packagist.org/packages.json，说明 fallback 了，配置没起作用。
http-max-concurrent-downloads 和 parallel-downloads 该设哪个
新版 Composer（2.2+）只认 http-max-concurrent-downloads，parallel-downloads 已弃用，设了也不生效，且无任何警告。
正确命令是：composer config -g http-max-concurrent-downloads 10（推荐值 8–10，别超 12）。
注意：
• 某些企业网络对并发连接敏感，如果出现 file_get_contents(): SSL operation failed，就降回 8
• CI 场景下建议组合使用 --no-dev --prefer-dist --no-autoloader --no-scripts，并缓存 ~/.composer/cache
