composer config -g repo.packagist 总不生效是因为键名必须为 repo.packagist（非 repos.packagist）、type 值 composer 不可省略、URL 必须 HTTPS 且末尾带 /、必须加 -g，任一缺失均静默回退官方源，验证需输出完整 JSON 对象。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任意一个细节——键名、type、斜杠——都会静默回退到 packagist.org，表面成功，实际没加速。
为什么 composer config -g repo.packagist 总是不生效
它不报错，也不提示失败，但根本没写进去。常见错误包括：
-
repos.packagist（多一个s）→ Composer 完全忽略该字段 -
composer config -g repo.packagist https://mirrors.aliyun.com/composer/（漏掉中间的composer）→ 缺少type值，新版直接 fallback -
https://mirrors.aliyun.com/composer（末尾没/）→ 请求路径变成/composerpackages.json，404 或空响应 - 没加
-g→ 只改当前项目composer.json，换目录就失效
验证是否真写进去了，只看这一条命令输出：composer config -g repo.packagist。必须返回类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON；返回空、null、或仍是 https://packagist.org，说明配置失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置比全局更可靠，但别覆盖已有源
CI/CD、宝塔、Docker 里常以 www 或 runner 用户运行，根本读不到你本地 root 或当前用户的全局配置。项目级配置可提交 Git，所有人行为一致。
- 进项目根目录，运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不带-g） - Composer 会自动识别已有
repositories结构：是对象就转成数组并追加，是数组就直接 push 新项，不破坏私有源 - 千万别手动在
composer.json里写"packagist": false—— 这会导致php、ext-json等基础约束校验失败 - 改完立刻运行：
composer update --lock，确保composer.lock记录的是镜像源地址
换源后还是卡在 Downloading？用 -vvv 看真实请求地址
光看命令执行完没报错没用。真正卡住时，得靠日志确认是否走对了源：
- 执行：
composer require monolog/monolog -vvv - 观察终端输出里 HTTP 请求的 URL，重点确认是否含
mirrors.或对应镜像域名（如cloud.tencent.com） - 如果仍看到
packagist.org/packages.json或packagist.org/files/xxx.zip，说明镜像完全没命中 - 临时验证可用：
composer create-project laravel/laravel myapp --repository=https://mirrors.aliyun.com/composer/（--repository优先级最高，仅当次有效）
有些镜像（如清华源）要求 secure-http: true，否则 HTTPS 校验失败；华为云镜像部分路径需手动补 /composer 后缀，不能直接用根路径——这些细节不显式暴露在命令里，只能靠 -vvv 日志反推。
