composer config -g repo.packagist 不生效的根本原因是三个硬性条件未同时满足：键名必须为单数 repo.packagist、type 值必须显式写 composer、url 必须 https 且末尾带 /；任一缺失即静默回退官方源，返回空或 null 且无报错。
composer config -g repo.packagist 命令为什么总不生效
不是网络问题，是命令写错了三个硬性条件，且 Composer 会静默失败——查 composer config -g repo.packagist 返回空或 null 就说明没配成。
-
repo.packagist必须是单数，写成repos.packagist（多一个s）就存进无用字段，完全不读 -
composer是必填的type值，不是注释也不是可选参数；漏掉它，Composer 2.0+ 直接 fallback 到官方源 - URL 必须是 HTTPS 且末尾带
/，少斜杠会拼出/composerpackages.json导致 404，然后静默回退
正确命令只有一条：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
全局镜像 vs 项目级配置：哪个更值得依赖
全局看着省事，但 CI、宝塔、Docker 构建里实际执行用户（如 www 或 runner）根本读不到 /root/.composer/config.json，配置等于白设。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 项目级配置运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意没-g），会直接写进当前项目的composer.json的repositories字段，Git 提交后团队行为一致 - 如果项目已有
"repositories": []（数组格式），这条命令会失败；得先手动改成"repositories": {}（空对象）再执行 - 项目级配置优先级高于全局，哪怕你全局配了，只要
composer.json里有"packagist.org": false这类语句，镜像照样被绕过
换镜像后 still stuck at “Loading repositories”？别急着重装
这不是镜像没生效，而是请求压根没发到镜像站——大概率是项目配置覆盖或禁用了源。
- 先分别运行
composer config -g repo.packagist和composer config repo.packagist，看哪一层在起作用 - 检查
composer.json是否存在"repositories"字段，尤其留意有没有"packagist.org": false或"packagist": false - 换源后首次
composer install报 hash 校验失败？删掉vendor和composer.lock再重来，旧 lock 文件里的元数据和镜像不匹配
composer require 版本约束不加 ^ 或 ~ 就等于锁死
composer require guzzlehttp/guzzle:7.5 看似简洁，实际等价于 "7.5.0"，几乎找不到匹配包；Composer 解析为精确版本，失败率极高。
- 用
^7.5表示兼容7.5.x，支持向后兼容的小版本/补丁升级，日常开发最安全 - 用
~7.5.0表示兼容7.5.0–7.6.0，适合对版本边界敏感的场景 -
--dev必须显式加，phpunit/phpunit这类工具漏掉它就会进require区，上线时可能加载冲突 -
--no-update适合只改声明不立即安装，比如想先确认composer.json变更再统一跑update
镜像只加速下载，不解决 Resolving dependencies 卡顿；那通常是 PHP 版本约束太宽、dev 包太多或 require-dev 工具链堆叠导致的——和镜像无关，得调 composer.json 本身。
