composer镜像配置不生效的三大硬伤：键名必须为repo.packagist（非repos或repositories.packagist.org）、第二参数必须显式写composer（声明type）、url须https且末尾带/；任一错误即静默回退官方源。
配错一个字符，Composer 就安静地连回 packagist.org —— 不报错、不提示、卡在 Downloading 或 Loading repositories，本质不是网络差，是镜像根本没生效。
composer config -g repo.packagist 命令为什么总不生效
这条命令静默失败的三大硬性条件缺一不可：
-
repo.packagist是唯一合法键名（不是repos.packagist、repositories.packagist.org或mirror） - 中间的
composer是必须显式声明的type值，漏掉就 fallback 到官方源 - URL 必须是 HTTPS 且末尾带
/（https://mirrors.aliyun.com/composer/✅，少斜杠会拼成/composerpackages.json导致 404）
正确写法只有一条：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。执行后必须立刻验证：composer config -g repo.packagist 输出应为完整 URL 字符串或标准 JSON 对象；返回 null、空值、https://packagist.org 或报错，说明配置失败。
怎么确认 Composer 真正在用国内镜像
别信配置命令的输出，要看它实际发出去的请求：
- 运行
composer diagnose，找到Repo packagist.org:这一行，后面域名必须是你配的镜像（如mirrors.aliyun.com） - 新建空目录，执行
composer init -n && composer require monolog/monolog -vvv，日志第一行Downloading https://...的域名必须匹配镜像地址 - 若仍看到
packagist.org/packages.json，立刻检查：项目级配置（composer config repo.packagist）优先级高于全局，会完全屏蔽-g设置
真实生效的日志特征是类似 Reading packages.json from cache at /https---mirrors-aliyun-com-composer/ —— 路径里出现镜像域名的转义形式，才是真走镜像。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
项目级配置比全局更可靠，尤其在 CI/CD 中
全局配置在宝塔、Docker、GitLab Runner 等场景下极易因用户权限失效（比如 www 用户读不到 root 的 ~/.composer/config.json），而项目级配置直接写进 composer.json，拉代码即生效：
- 进项目根目录，执行：
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（注意不加-g） - 该命令自动向
composer.json的repositories字段追加"packagist"条目，不会覆盖已有私有源（前提是repositories是对象结构，不是数组） - 如果
composer.json已有"repositories": []数组，别手动编辑 JSON —— 格式错一个逗号就会让composer install直接报错；改用命令追加，或手动在数组中插入新对象并确保保留原有私有源
换源后仍卡住？必须清缓存：composer clear-cache，再删掉 vendor/ 和 composer.lock，最后跑 composer install --no-cache —— 旧 composer.lock 记录的是 packagist.org 的包哈希，和镜像元数据不兼容，必然触发 hash does not match。
换源后还卡在 “Resolving dependencies”？和镜像无关
镜像只加速下载和元数据拉取，不解决依赖解析阶段的卡顿。如果你发现 composer update 卡在 Resolving dependencies through SAT 几十秒甚至几分钟，问题出在本地：
- PHP 内存不足：默认 128M 不够，临时加
COMPOSER_MEMORY_LIMIT=-1 - Xdebug 启用中：会让解析慢 5–10 倍，用
php -d xdebug.mode=off $(which composer) install临时禁用 - 版本约束太宽：比如
"php": "^7.4 || ^8.0"或"monolog/monolog": "dev-main"，会触发大量组合穷举 -
classmap-authoritative开启：Composer 3.x 默认启用，每次 update 都强制重扫整个vendor/目录，纯 I/O 开销
真正容易被忽略的是：换源之后，composer.lock 文件本身已失效。它不是“缓存”，而是锁定了旧源的包路径与哈希。不删它，哪怕镜像全速运转，Composer 也会在验证环节反复失败、重试、降级，最终卡死在你完全没意识到的地方。
