composer config -g repo.packagist 命令总不生效，90% 是因未满足三个硬性条件：必须带 -g、键名严格为 repo.packagist（非 repos 或 packagist.org）、composer 类型值不可省略；URL 必须 HTTPS 且末尾带 /，否则静默回退官方源。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，是命令写错三个硬性条件：必须带 -g、键名必须是 repo.packagist（不是 repos.packagist 或 packagist.org）、composer 类型值不能省略。漏掉任意一个，命令静默失败——不报错，但 composer config -g repo.packagist 输出为空或仍是 https://packagist.org。
URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ 合法，https://mirrors.aliyun.com/composer 或 http://... 都会 fallback 到官方源。验证方式只有这一种：composer config -g repo.packagist，输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
- Windows 用户执行后需重启 PowerShell/CMD，否则读不到新配置
- PHP 环境若禁用了
proc_open或putenv（常见于宝塔、Docker 容器），config -g会直接报错，需检查php.ini并重启 PHP 服务 - Composer 2.2+ 不再兼容旧键名
repos.packagist，那是 Composer 1.x 的写法
项目级镜像配置为何比全局更可靠
CI 流水线、宝塔面板、GitLab Runner 这些环境默认以非登录用户（如 www、runner）运行，根本读不到你本地 ~/.composer/config.json 里的全局配置。项目级配置写进 composer.json，能被 Git 跟踪、被所有环境一致读取。
但注意：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带 -g）会**全量替换** composer.json 中的 repositories 字段，不是追加。如果项目已有私有 VCS 源，这条命令会把它清空。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 安全做法：手动编辑
composer.json，在顶层添加"repositories"数组，首位放阿里云镜像对象，确保"packagist.org": true（千万别设为false，否则基础包全拉不到） - 已有
composer.lock时，换镜像后必须删掉vendor/和composer.lock，再跑composer install，否则哈希校验失败 - 项目级配置优先级高于全局，所以即使全局配了，项目里写了
repositories，也只认项目级
多个镜像源怎么配才真正起作用
Composer 不并行查源，而是按 repositories 数组顺序逐个尝试，第一个能返回包信息的源就用它，后面全跳过。把国内镜像放前面、官方源放最后兜底，才是有效多源。
错误写法是把 packagist.org 放第一位，结果所有请求都走海外慢通道，镜像完全失效。正确结构示例：
"repositories": [
{
"type": "composer",
"url": "https://mirrors.aliyun.com/composer/"
},
{
"packagist.org": false
}
]- 不要手写
"packagist.org": false在repositories内部——它必须是顶层字段，否则无效 - 私有包源（如 GitLab）必须用
"type": "vcs"，且放在repositories最前面，否则同名公共包会被优先匹配 - 某个镜像临时不可用时，Composer 会静默跳过，不会报错；加
-vvv参数看日志里是否出现你的镜像 URL，才能确认是否真走了该源
换镜像后还是卡在 Resolving dependencies 怎么办
镜像只加速下载，不解决依赖解析慢的问题。卡在这里，和镜像无关，大概率是 composer.json 写法或本地环境导致的。
-
"php": "^7.4 || ^8.0"这类宽泛约束会让 Composer 尝试大量版本组合，拖慢解析；应锁定最小必需版本，比如"php": "^8.1" - 避免在
require-dev里塞太多未锁定的工具包，尤其是"dev-main"这类分支引用，它们每次都要重新 resolve - 确保已启用
openssl和zlib扩展：php -m | grep -E 'openssl|zlib'，缺一个都可能让 metadata 请求失败 - 某些 IDE 或 Docker 环境会干扰 DNS 解析，可临时加
--verbose看卡在哪一步，再针对性排查
最常被忽略的是：镜像配置完不清理缓存，也不删旧 composer.lock，结果 Composer 还在按老路径找包，根本没走新镜像。
