根本原因是命令写错：键名必须为repo.packagist（单数）、type值必填composer、URL须以https://开头且末尾带/，三者缺一即静默回退官方源。
composer config -g repo.packagist 命令为什么总不生效
根本原因不是镜像地址失效，而是命令本身写错三个关键点就静默失败：键名必须是 repo.packagist（单数、无s），composer 是必需的 type 值（不能省），URL 必须以 https:// 开头且末尾带 /。漏掉任意一个，composer config -g repo.packagist 返回空或 null，但不报错。
常见误操作：
- 写成
repos.packagist（多一个 s），配置被写进无效字段 - 漏掉
composer类型声明，Composer 2.0+ 直接 fallback 到官方源 - 用
http://或末尾缺/，部分版本会拼出错误路径导致 404 - 在 root 用户下执行
composer config -g，但宝塔/CI 实际以www或runner用户运行，读的是另一个家目录下的~/.composer/config.json
换镜像后 composer update 还卡在 Resolving dependencies
镜像只加速下载，不参与依赖解析。如果 composer update 卡在 Resolving dependencies 阶段几十秒以上，和镜像无关，是本地约束或环境问题：
-
composer.json里 PHP 版本写得太宽，比如"php": "^7.4 || ^8.0"，让 Composer 要遍历大量不兼容组合 -
require-dev里塞了太多未锁定版本的工具链（如phpunit/phpunit不带版本号） - 项目用了大量
dev-分支依赖，每次都要重新 fetch 元数据 - PHP 扩展缺失（
openssl、zlib未启用）会导致解析中途失败，表现为“卡住”
composer update 默认行为与锁文件冲突
composer update 默认读 composer.lock 并按它更新子依赖，但如果你改过镜像源，旧 lock 文件里的 hash 可能和新镜像元数据不匹配，导致校验失败或拉不到包。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
推荐做法：
- 换源后首次运行，先删掉
composer.lock和vendor/目录 - 再跑
composer install，它会按composer.json重新解析并生成新 lock 文件 - 避免无差别
composer update——生产环境应指定包名，例如composer update monolog/monolog - 想跳过开发依赖？加
--no-dev；想强制忽略 lock 文件？用composer update --lock（等效于删 lock 后 install）
全局配置 vs 项目级配置：什么时候该用哪个
全局配置（composer config -g）看着省事，但实际容易出问题。项目级配置写进 composer.json 的 repositories 字段更可靠，尤其在团队协作和 CI 场景下。
项目级配置要点：
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 它会自动往
composer.json顶层写入"repositories"对象，key 固定为"packagist" - 如果已有
"repositories": []（数组格式），命令会报错，需先手动改成对象"repositories": {} - 别手写
"packagist.org": false，这会彻底关掉官方源，镜像不可用时直接失败
真正麻烦的从来不是换源本身，而是配置没落到实际执行命令的那个用户身上，或者锁文件残留旧元数据——这两点不清理，换再快的镜像也白搭。
