composer config -g repo.packagist 命令生效需同时满足四个硬性条件：键名必须为 repo.packagist（单数）、type 值显式指定为 composer、URL 必须是 HTTPS 且末尾带 /、必须使用 -g 全局标志，缺一即静默回退至官方源。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，是四个硬性条件缺一不可：repo.packagist（单数键名）、composer（type 值必须显式写出）、https://mirrors.aliyun.com/composer/（URL 必须 HTTPS 且末尾带 /）、-g（全局标志）。漏一个就静默 fallback 到 https://packagist.org，命令返回 0 却毫无作用。
常见失败组合：
-
composer config -g repo.packagist https://mirrors.aliyun.com/composer/→ 缺composertype，Composer 不识别，直接忽略 -
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer→ 少/，请求路径变成/composerpackages.json，404 但不报错 -
composer config -g repo.packagist composer http://mirrors.aliyun.com/composer/→ HTTP 被 Composer 2.2+ 默认拒绝
验证是否真写入：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null 或仍是 https://packagist.org 都说明根本没生效。
CI/CD 或 Docker 构建中镜像源为何失效
全局配置 composer config -g 写入的是当前用户家目录下的 ~/.composer/config.json。CI 环境（如 GitHub Actions、GitLab CI）常以 root、www-data 或其他非登录用户身份执行命令，你本地配的配置对它完全不可见。
更隐蔽的问题是缓存干扰：CI runner 可能复用旧缓存，或构建镜像时未清掉旧 vendor/ 和 composer.lock，导致 Composer 仍从 lock 文件里读取原始元数据地址，根本没触发新镜像。
推荐做法：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在 CI 脚本开头显式重置一次：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 强制清理：
composer clear-cache && rm -rf vendor/ composer.lock - 加
-vvv参数跑composer install，grep日志确认出现mirrors.aliyun.com而非packagist.org - 改用项目级配置：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/，提交composer.json到 Git，所有环境自动继承
镜像同步延迟与临时不可用怎么快速应对
国内镜像不是实时同步，阿里云、腾讯云等通常有 5–30 分钟延迟，尤其小众包或刚发版的 dev-main 分支。遇到 Could not find package xxx at any version，先查 https://mirrors.aliyun.com/composer/packagist/ 是否已收录该包。
若镜像站网页能搜到但 CLI 报错，尝试清缓存：composer clear-cache。
镜像临时下线或 DNS 解析异常时，Composer 不会自动 fallback，它只认 composer config -g repo.packagist 里存的那个地址。实操建议：
- 先运行
composer config -g repo.packagist确认当前全局镜像地址 - 用
curl -sS https://mirrors.aliyun.com/composer/packages.json | head -n1测试该地址是否可访问（比curl -I更准） - 如果不可达，立刻切到备用镜像——别等“官方通知”，镜像维护通常不发公告
- 快速切换命令示例：
切华为云：composer config -g repo.packagist composer https://repo.huaweicloud.com/repository/php/
切腾讯云：composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/
切清华源：composer config -g repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/
代理和镜像能不能一起用
不能。镜像源（如 https://mirrors.aliyun.com/composer/）和 http.proxy 是互斥配置项：设了前者，后者自动失效。你改了 repo.packagist.url，Composer 就直连镜像站，绕过所有代理逻辑。
只有当你必须连真实 packagist.org 或企业私有 Packagist（且启用了 mTLS）时，才需要代理；此时镜像源退场，http.proxy 才起作用。
如果你身处强管控内网，又无法直连镜像站，唯一稳解是跳过镜像，让 Composer 自带证书直连目标域名——前提是运维已将镜像域名加入白名单或部署了内部代理服务。硬凑代理 + 镜像，只会让 TLS 握手失败、DNS 解析抖动、超时循环反复发生。
