必须显式添加{"packagist.org": false}到repositories数组末尾，否则Composer仍默认优先请求packagist.org；该false项须为独立对象、不可嵌套，且键名仅认"packagist.org"（非repo.packagist等变体）。
composer config repositories 里混写了 packagist.org 和镜像 URL
这是最常踩的坑：你以为把阿里云镜像写在 repositories 数组第一位就能生效，结果 composer install 还是去请求 https://packagist.org。根本原因是没禁用默认源——Composer 会先查 packagist.org，只有它返回 404 才轮到你写的镜像。
- 必须显式添加
"packagist.org": false到repositories数组中，且作为独立对象（不是嵌套在某个 URL 下） - 这个
false对象要放在数组末尾，否则可能被前面的镜像配置干扰解析 - 检查方式：运行
composer config repositories，输出里必须有"packagist.org": false，且其他条目只含你认可的镜像 URL（如"https://mirrors.aliyun.com/composer/"） - 别写
"repo.packagist"或"repos.packagist.org"——Composer 2.2+ 只认"packagist.org"这个键名
全局插件和项目依赖共用同一镜像配置但行为不一致
你给全局配了清华镜像，项目里又写了腾讯云镜像，结果发现 php-cs-fixer 报错找不到类，而 composer update 却正常。这不是镜像冲突，而是 autoload 隔离导致的路径错乱。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局插件（
composer global require）只读~/.composer/config.json，完全无视项目里的repositories - 项目依赖（
composer install）只读当前目录下的composer.json或composer.lock，不继承全局镜像 - 验证方法：分别运行
composer global config repositories.packagist.org和composer config repositories.packagist.org，看输出是否不同 - 如果想让两者行为一致，就不要混用全局插件；改用项目级 bin 工具（如
./vendor/bin/php-cs-fixer）
插件仓库（如 Composer plugin）绕过镜像直连 GitHub
有些插件（比如 hirak/prestissimo 或自定义 installer）在安装时会直接克隆 Git 仓库，这类操作不走 Composer 的镜像机制，也不受 repositories 控制——它只管元数据下载，不管 source 克隆。
- 现象：日志里看到
Cloning https://github.com/xxx/yyy.git，哪怕你已配好阿里云镜像 - 原因：镜像只代理 dist（ZIP 包），不代理 Git 源；source 模式下 Composer 直连 GitHub
- 解决方向不是换镜像，而是确认该插件是否支持 dist-only 安装（看其
composer.json是否含"dist"字段） - 若必须走 source，就得单独处理 GitHub 访问问题：配
github-oauth、调大 Git 超时、或改用企业内网 Git 代理
composer.lock 里记录的是旧源地址，换镜像后仍卡在 packagist.org
你改完镜像、清了缓存、甚至删了 vendor，但 composer install -vvv 日志里还是出现 Downloading https://packagist.org/p2/xxx.json。大概率是 composer.lock 文件里固化了旧的 dist URL 和 hash，Composer 优先复用它而不是重新解析元数据。
- 执行
composer update --lock强制刷新 lock 文件中的下载地址（注意：这会重算依赖，可能升级版本） - 更稳妥的做法是先删掉
composer.lock，再跑composer install，让 Composer 从头拉取元数据 - CI/CD 中建议加一步：
composer clear-cache && rm -f composer.lock，避免缓存和 lock 文件双重干扰 - 别只信
composer clear-cache——它不清理packages.json的内存缓存，真正有效的是composer update --refresh（Composer ≥ 2.5）
repositories 结构，而不是你“以为”配对了的位置或拼写。最容易被忽略的是 packagist.org 的显式禁用时机、composer.lock 的残留影响，以及 source 模式下 Git 克隆与镜像机制的天然隔离。 
