必须配置国内镜像，否则在国内基本无法安装依赖；composer config -g repo.packagist命令90%失效源于键名拼错（如repos.packagist）、漏写type值composer、URL缺末尾斜杠，且均静默回退官方源，需用-vvv日志和config输出双重验证。
composer 不配国内镜像，在国内基本装不了依赖——不是慢，是大概率卡在 Downloading、报 could not find package 或直接 403。镜像不是“锦上添花”，是能跑起来的底线。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，是命令本身写错了，且 Composer 会静默回退到官方源，不报错也不提示。
-
repo.packagist不能拼成repos.packagist（多一个 s 就彻底失效） - 中间那个
composer是type值，必须显式写出；漏掉它，命令看似执行成功，但实际没存任何有效配置 - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（缺斜杠会 404）
验证是否真写进去了：运行 composer config -g repo.packagist。输出必须是完整 JSON 对象（如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）或新版仅显示该 URL 字符串。如果返回空、null、https://packagist.org，说明完全没生效。
宝塔、CI、Docker 里全局配置为啥还是卡
全局配置写在当前用户的 ~/.composer/config.json 里，只对该用户生效。而宝塔默认用 www 用户执行 PHP 管理器和一键部署，GitHub Actions 用 runner 用户，Docker 容器里可能是 www-data 或自定义 UID —— 它们根本读不到你本地 root 或 admin 的配置。
- 先确认实际执行用户：在宝塔终端里运行
whoami，或查计划任务日志里的 UID - 给对应用户重配：比如是
www，就执行sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中，确保
composer config -g和后续composer install是同一个用户身份（例如 GitHub Actions 中加run-as: ${{ secrets.DEPLOY_USER }}）
项目级配置怎么安全追加而不覆盖私有源
进项目根目录后执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加 -g），这条命令会自动识别已有 repositories 结构并追加，而不是粗暴覆盖。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
立即学习“PHP免费学习笔记（深入）”；
- 如果
composer.json原本是"repositories": {}，它会转为标准数组并插入 packagist 条目 - 如果原本是
"repositories": [ { "type": "vcs", "url": "git@xxx" } ]，它会在数组末尾追加新对象，不破坏原有 Git 源 - 千万别手动写
"packagist": false，这会导致基础扩展（如ext-json、php版本校验）直接失败
改完建议立即运行 composer update --lock，让 composer.lock 记录新镜像地址，避免协作时因 lock 文件残留旧源导致签名不匹配。
换镜像后还是卡？盯紧 -vvv 日志里的真实请求地址
-vvv 是唯一可信证据。加了它，composer install -vvv 会逐行打印 HTTP 请求 URL。
- 看到大量
GET https://mirrors.aliyun.com/composer/→ 镜像已生效，问题在下载环节（可检查磁盘 I/O 或缓存路径） - 长时间停在
Resolving dependencies→ 和镜像无关，是本地 PHP 内存不足、启用了xdebug、或composer.json里约束太宽（比如"*"或"minimum-stability": "dev"） - 请求地址仍是
https://packagist.org→ 镜像根本没走，立刻回头检查composer config -g repo.packagist输出
真正容易被忽略的是：镜像只加速元数据拉取和 ZIP 下载，不解决依赖求解本身的 CPU 暴力计算。如果项目长期卡在这一步，删掉 minimum-stability、收紧 php 版本约束、关掉 xdebug，比换十个镜像都管用。
