composer config -g repo.packagist 静默失效的主因是三要素未同时满足：键名必须为单数 repo.packagist（非 repos）、第二参数 composer（type 值）不可省略、URL 必须以 / 结尾；任一缺失均导致配置为空或 null，且不报错。
composer config -g repo.packagist 这条命令必须成功写入，否则所有后续操作都还在直连 packagist.org——不是慢，是根本没切过去。
为什么 composer config -g repo.packagist 经常静默失效
它不报错，但也不生效，是最容易被忽略的“假成功”。常见原因就三个：
-
repo.packagist写成repos.packagist（多一个s），命令执行成功，但 Composer 完全不认这个键 - 漏掉中间的
composer类型参数，比如写成composer config -g repo.packagist https://mirrors.aliyun.com/composer/，缺少composer，type字段就为空 - URL 末尾没加
/，https://mirrors.aliyun.com/composer是错的，必须是https://mirrors.aliyun.com/composer/
验证方式只有一种：composer config -g repo.packagist。输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或只返回字符串（不含 type）都代表失败。
项目级配置怎么不破坏已有私有源
直接运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）看似方便，但它会全量替换 composer.json 中的 repositories 字段，把已有的 Git 私有源、Satis 源一并清空。
安全做法是手动编辑 composer.json，确保结构如下：
{
"repositories": {
"packagist": {
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
},
"my-private": {
"type": "vcs",
"url": "https://git.example.com/pkg"
}
},
"packagist.org": false
}
注意两点：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"packagist.org": false必须写在根节点，不是嵌套在repositories里；否则私有源和镜像共存时可能冲突 - 别写
"packagist": false，这会导致基础扩展（如ext-json）校验失败
宝塔、CI 或多用户环境里全局配置为啥不生效
因为 composer config -g 只写当前用户的配置文件：/root/.composer/config.json 或 /home/www/.composer/config.json。但宝塔“一键部署”用的是 www 用户，GitHub Actions 用的是 runner 用户，它们根本读不到你本地 root 或 admin 的配置。
解决方法分场景：
- 宝塔中：用
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中：别依赖全局配置，改用临时参数，例如
composer install --no-dev --prefer-dist --repository-url=https://mirrors.aliyun.com/composer/ - 团队协作：优先走项目级配置，把镜像写进
composer.json并提交 Git，所有人行为一致
换了镜像还卡在 Resolving dependencies？和镜像无关
这个阶段完全不走网络，镜像再快也没用。真正瓶颈通常来自：
- PHP 内存不足（默认 128M），跑复杂依赖图直接重试——临时加
COMPOSER_MEMORY_LIMIT=-1测试 - Xdebug 启用了（
php -v看输出），会让解析慢 5–10 倍——用php -d xdebug.mode=off $(which composer) install临时关掉 -
composer.lock里残留已下线包的 hash，导致回退搜索——删掉vendor和composer.lock，再composer install --no-cache - platform 配置与实际 PHP 版本不匹配，比如
"php": "7.4"却在 PHP 8.2 上运行，触发降级查找逻辑
真正需要镜像加速的阶段只有两个：元数据拉取（packages.json）、tarball 下载（.zip 包）。其他环节优化得再细，也绕不开 PHP 环境本身。
