Composer config -g repo.packagist 失效主因是三个硬性条件缺一不可：键名必须为单数 repo.packagist、type 值必须显式写 composer、URL 必须 HTTPS 且末尾带 /，任一不满足即静默回退官方源。

composer config -g repo.packagist 命令为什么没生效

大概率是三个硬性条件漏掉一个：键名写成 repos.packagist（多了一个 s）、漏掉 composer 这个 type 值、URL 末尾没加斜杠 /。这三处任一出错，Composer 2.x 都会静默 fallback 到官方源，不报错也不提示。

• repo.packagist 是固定键名，不能写成 packagist.org 或 repositories.packagist
• composer 是必须显式声明的 type 值，不是可选参数
• URL 必须是 HTTPS，且末尾带 /，例如 https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌
• 验证是否写入成功，直接运行 composer config -g repo.packagist；输出必须是完整 JSON 对象或至少是纯 URL 字符串，空、null、报错或只返回 https://packagist.org 都说明失败

项目级配置怎么避免覆盖私有仓库

执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）会**全量替换**当前项目的 composer.json 中的 repositories 字段，不是追加——如果你原本已配了 Git 私有源或 Satis 源，这条命令会直接清空它们。

• 已有 "repositories": { "my-private": { "type": "vcs", ... } }？别跑命令，手动编辑 composer.json，在 repositories 数组里加一条：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
• 同时确保根节点写上 "packagist.org": false（注意：不是写在 repositories 内部），否则私有源 + 镜像共存时可能冲突
• 改完后必须运行 composer update --lock，确保 composer.lock 记录新源地址

换镜像后仍卡在 Downloading，怎么验证真走镜像了

composer config -g repo.packagist 只告诉你“配了什么”，不告诉你“用了什么”。项目级 repositories 会直接覆盖全局配置，且 config -g 完全查不到它。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 删掉 vendor/ 和 composer.lock，再执行 composer install -vvv 2>&1 | grep "GET "
• 真正生效的标志是日志里出现类似 GET https://mirrors.aliyun.com/composer/p2/monolog/monolog.json，而不是 packagist.org 或 api.github.com
• 看到 GET https://packagist.org/packages.json，说明镜像完全没走通，哪怕 config -g 显示正确也没用
• 别信 ping 或单点 curl 测速——实际请求路径是 /p2/xxx.json 和 /dist/xxx.zip，CDN 缓存命中率才是关键

宝塔/CI 环境里全局配置为啥不起作用

全局配置写在 /root/.composer/config.json，但它只对 root 用户生效。宝塔「一键部署」、PHP 管理器、计划任务默认以 www 用户运行，根本读不到 root 的配置。

立即学习“PHP免费学习笔记（深入）”；

• CI 环境（如 GitHub Actions）默认用 runner 用户，也读不到你本地的全局配置
• 团队协作时，不同成员的全局配置不一致，会导致 composer install 行为不一致、composer.lock hash 不同
• 解决方案：一律采用项目级配置，提交到 Git，CI 构建时自动生效，无需额外 setup
• 如果非要用全局配置，需确保目标用户（如 www）也有对应权限，并执行 sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/

镜像本身是代理，不是魔法——如果本地 DNS 解析慢、公司防火墙拦截 HTTPS、或镜像源同步滞后，光改配置也救不了。真正卡住的时候，先 ping mirrors.aliyun.com 和 curl -I https://mirrors.aliyun.com/composer/packages.json 看底层通不通，比反复调 Composer 参数更省时间。