composer config -g repo.packagist 总不生效是因为必须同时满足三个硬性条件：键名必须为单数 repo.packagist、中间必须显式写 composer（type 值）、URL 必须 HTTPS 且末尾带 /；任一缺失即静默回退官方源，验证需输出完整 JSON 对象。
composer config -g repo.packagist 为什么总不生效
根本不是网络问题，而是命令漏了三个硬性条件，Composer 2.x 就会静默 fallback 到 https://packagist.org，不报错、不提示、也不写入配置。
-
repo.packagist必须是单数、小写、无 s —— 写成repos.packagist或packagist.org都无效 - 中间的
composer是type值，不是注释、别名或可选参数，必须显式写出 -
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/"}。返回空、null、Key "repo.packagist" does not exist，或只有一行 URL 字符串，都说明失败。
项目级配置为什么比全局更可靠
全局配置（加 -g）只写进当前用户的 ~/.composer/config.json，但宝塔用 www 用户、GitHub Actions 用 runner 用户、Docker 容器甚至没有你的家目录——配了等于没配。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 进项目根目录（确保有
composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会自动往
composer.json顶层的repositories字段安全追加，key固定为"packagist"，不会覆盖已有私有源 - 前提是
"repositories"是对象格式（{}）；如果原先是数组（[]），命令会直接报错，需先手动改成空对象再重试 - 切勿手写
"packagist.org": false—— 这会彻底关掉基础包校验，连php或ext-json都装不上
换源后 vendor 和 composer.lock 为什么必须删掉
镜像只加速元数据下载和 ZIP 包拉取，但 composer.lock 里存的是旧地址（比如 dist.url 指向 codeload.github.com），vendor/ 里也缓存着旧路径的解析结果。不清理就跑 composer install，它照样走官方源。
- 先执行：
composer clear-cache - 再删掉项目下的
vendor/和composer.lock - 最后运行：
composer install（不是update）——只有install会按新镜像地址重新解析并生成新的lock文件 - 如果日志里仍出现
packagist.org或codeload.github.com，说明镜像根本没走通，回头检查前两个副标题里的硬性条件
哪些镜像地址现在还能用（2026 年 8 月实测）
截至今天，只有这三个镜像全量同步、HTTPS 强制、延迟稳定（5 分钟内），其余旧地址基本不可靠：
- 阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云（部分区域可用）：
https://mirrors.huaweicloud.com/composer/
临时验证某个镜像是否可用，可用 --repository 参数单次生效：composer create-project laravel/laravel myapp --repository=https://mirrors.aliyun.com/composer/。注意：这个参数不改任何配置，只对当前命令起作用。
