Composer config -g repo.packagist 命令总不生效是因为未满足三个硬性条件：键名必须为单数repo.packagist、type值强制为composer、URL须HTTPS且末尾带/，任一错误均静默回退官方源，且需删除vendor和composer.lock才能生效。
composer config -g repo.packagist 命令为什么总不生效
不是镜像服务挂了，而是命令写错了三个硬性条件，Composer 会静默失败、不报错、也不提示。
必须同时满足：
-
repo.packagist是唯一合法键名（不能是repos.packagist、repositories.packagist或packagist.org） - 中间的
composer是强制 type 值，不能省略，也不能替换成vcs、package等其他类型 - 镜像 URL 必须用 HTTPS，且末尾必须带斜杠：
https://mirrors.aliyun.com/composer/（漏掉/会导致请求路径拼成/composer/packages.json而返回 404）
验证是否真写进去了：运行 composer config -g repo.packagist。输出应为完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或报 Key not found，说明没写对，立刻重试。
删 vendor 和 composer.lock 是硬性前提
镜像配置只影响「元数据拉取」和「新包下载地址」，但 composer.lock 文件里存的是每个包的 dist.url——这是固化下来的下载链接，跟当前配置无关。
只要 composer.lock 存在，Composer 就直接按它里面的 URL 下载，完全跳过镜像设置。
所以：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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（不是update），才能触发全新依赖解析 + 全部从新镜像拉取 - 如果只跑
composer update，它可能沿用旧 lock 里的官方 URL，导致依然超时或 404
项目级配置比全局更可靠，但要注意 repositories 格式
全局配置在 CI、宝塔、Docker 构建中经常失效——因为 composer config -g 写的是当前用户的 ~/.composer/config.json，而实际运行命令的可能是 www、runner 或容器内无家目录的用户。
项目级配置写进 composer.json，可 Git 提交、团队一致、CI 可复现。但有两处关键细节：
- 运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g）时，它只会安全追加一个"packagist"键到"repositories"对象里——前提是原repositories是对象（{}），不是数组（[]） - 如果
composer.json里已有"repositories": []，该命令会报错；需先手动改成"repositories": {}再运行 - 别手写
"packagist.org": false—— 这会彻底禁用基础源，镜像一旦临时不可用，composer install直接失败
“Loading composer repositories” 卡住 ≠ 镜像没生效
这个阶段卡住，90% 是 DNS 解析慢或 TLS 握手失败，而不是镜像地址写错了。但即使镜像 URL 正确，也可能根本没走到那一步。
排查顺序：
- 先确认镜像服务本身可达：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算正常 - 检查是否被本地代理或
http_proxy环境变量干扰（尤其公司网络） - 运行
composer config -g repo.packagist和composer config repo.packagist，看哪一层实际生效；项目级配置优先级高于全局 - 查看
composer.json是否存在"packagist.org": false或"packagist": false这类彻底关源的字段
真正容易被忽略的是：镜像只加速「元数据加载」和「ZIP 包下载」，不解决 Resolving dependencies 阶段的卡顿——那通常是 PHP 版本约束太宽、dev 分支引用过多或 require-dev 工具链臃肿导致的。
