Composer config -g repo.packagist 总不生效，根本原因是未满足三个硬性条件：键名必须为单数 repo.packagist（非 repos.packagist）、第二参数必须显式指定 type 值 “composer”、URL 必须以 / 结尾；任一缺失均静默回退官方源且不报错。
composer config -g repo.packagist 命令为什么总不生效
不是镜像挂了，大概率是命令写错了三个硬性条件，且 Composer 会静默失败、不报错。
-
-g缺失 → 配置只写进当前项目composer.json，换目录就失效 -
repo.packagist拼错（比如写成repos.packagist、packagist.org或漏掉repo.）→ 写入无效字段，查composer config -g repo.packagist返回空或null - 镜像 URL 少了末尾斜杠，如
https://mirrors.aliyun.com/composer→ 实际请求变成/composerpackages.json，404
正确写法只有一条：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。验证是否成功：运行 composer config -g repo.packagist，应输出类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的 JSON 对象。
项目级配置比全局更可靠，但要注意 repositories 格式
全局配置在 CI、宝塔、Docker 等多用户/多身份场景下极易失效——因为 ~/.composer/config.json 是按执行用户隔离的。项目级配置写进 composer.json，可提交 Git，所有人行为一致。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（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） - 该命令仅修改
repositories字段下的"packagist"子项，不覆盖已有私有源——前提是原"repositories"是对象（{}），不是数组（[]） - 如果
composer.json里已有"repositories": []，命令会报错；需先手动改成"repositories": {}再执行 - 别手写
"packagist.org": false—— 这会彻底禁用所有源，镜像不可用时composer install直接失败
换镜像后卡在 “Loading composer repositories” 怎么排查
这不是镜像没生效，而是请求根本没发出去。常见原因是配置被覆盖或显式禁用。
- 先查两层配置：
composer config -g repo.packagist（全局）和composer config repo.packagist（项目级），看哪一层实际在起作用 - 检查
composer.json是否存在"repositories"字段，并留意有没有"packagist": false或"packagist.org": false这类语句 - 临时验证镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json，返回200 OK才算服务正常 - 如果项目已配私有源，又想临时测新镜像，用
composer install --repository-url=https://mirrors.tencent.com/composer/（注意：仅install和update支持，require不支持）
“Resolving dependencies” 卡住和镜像无关
镜像只加速下载，不解决依赖解析慢的问题。如果你发现 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本和网络、镜像都无关。
-
"php": "^7.4 || ^8.0"这类宽泛版本约束会让 Composer 尝试大量组合，拖慢解析 - 大量使用
dev-main、dev-develop等未锁定分支，尤其跨多个包时，版本图爆炸增长 -
require-dev里塞了太多工具链（如phpunit、phpstan、psalm、infection），相互约束冲突 - 改完镜像后记得删掉
vendor和composer.lock重装，否则旧 lock 文件里的 hash 可能和镜像元数据不匹配
真正难调的是依赖关系本身，不是源地址——这点最容易被忽略。
