composer config -g repo.packagist 命令失效是因为必须严格满足三条规则：键名必须为 repo.packagist（不可拼错）、type 参数 composer 必须显式传入、URL 必须是 HTTPS 且末尾带 /；否则 Composer 静默回退至官方源。
composer config -g repo.packagist 命令为什么总不生效
不是网络慢，是命令写错后 Composer 会静默 fallback 到 https://packagist.org，连报错都没有。三条硬性规则缺一不可：
-
repo.packagist是固定键名——写成repos.packagist、packagist.org或mirror全部无效 - 中间必须显式传入
composer作为 type 参数：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉composer就等于没配 - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致请求/composerpackages.json而 404）
验证是否成功：运行 composer config -g repo.packagist，输出应为完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）或纯 URL 字符串；若为空、null、或仍是 https://packagist.org，说明根本没写进去。
项目级配置比全局更可靠，但别乱用 composer config repo.packagist
全局配置在宝塔、CI、systemd 服务中经常失效——因为它们不是以你当前用户身份运行的（比如宝塔用 www 用户，Jenkins 用 jenkins 用户）。项目级配置写进 composer.json，随代码提交，行为可预期，新人 clone 后直接 composer install 就行。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 它会自动向
composer.json的repositories字段追加packagist条目，不会清空已有私有源 - 如果
composer.json原本是"repositories": {}，命令会转成标准对象并插入；如果是"repositories": []，则追加到数组末尾 - 手动编辑更稳妥（尤其已有 Git 私有源时）：
{ "repositories": { "packagist": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" } } }注意packagist是固定 key 名，不能改成aliyun或其他名字
换源后还卡在 “Resolving dependencies”？这和镜像完全无关
这个阶段根本不走网络，是本地 CPU 在暴力穷举满足所有约束的版本组合。镜像只加速元数据拉取和 ZIP 下载，解决不了这里卡顿。
- 删掉
"minimum-stability": "dev"——开发版会让求解时间暴涨 80% - 收紧 PHP 版本约束：
"php": "^8.1"比"php": ">=7.4"少查几百个包的兼容性元数据 - 确保
composer.lock已提交，部署时始终用composer install（不是update） - 临时禁用 xdebug：
php -d xdebug.mode=off $(which composer) install，它会让解析慢 5–10 倍 - 检查内存限制：
COMPOSER_MEMORY_LIMIT=-1可缓解Resolving dependencies卡死
cURL error 60 或 HTTPS 证书报错？别换 HTTP 镜像
出现 cURL error 60: SSL certificate problem，不是镜像问题，是 PHP 的 openssl.cafile 没指向有效的根证书路径。阿里云、腾讯云、华为云镜像全用正规 DV 证书，不支持 HTTP 回退——降级等于自毁安全性。
- 查当前配置：
php -i | grep 'openssl.cafile' - Linux/macOS 常见修复：
export COMPOSER_CAFILE=/etc/ssl/certs/ca-certificates.crt（路径按实际调整） - Windows 用户建议用 Git Bash 运行，避免 cmd 下 OpenSSL 环境混乱
- 如果
composer diagnose提示 CA file 不 OK，先修这个，再动仓库配置
最常被忽略的是：PHP 版本、OpenSSL 编译方式、终端环境变量三者叠加，会让“换源”变成一长串排查链。稳的起点永远是确认 composer diagnose 输出里 HTTP proxy 和 CA file 都 OK，再动仓库配置。
