composer config -g repo.packagist 总不生效是因为必须同时满足三个硬性条件：键名严格为单数 repo.packagist、第二个参数显式指定 composer 类型值、URL 必须是 HTTPS 且末尾带 /，任一不符即静默回退官方源且不报错。
composer config -g repo.packagist 命令为什么总不生效
这条命令静默失败是 Composer 卡顿的头号原因——它不报错、不提示，但配置根本没写进去，后续所有操作都还在连 packagist.org。
必须同时满足这三点才真正写入全局配置：
-
repo.packagist键名必须是单数，写成repos.packagist或repositories.packagist全部被忽略 - 中间必须显式传入
composer作为 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，漏掉composer就 fallback - URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json导致 404）
验证是否成功：运行 composer config -g repo.packagist，输出必须是完整 JSON，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或仍是 https://packagist.org，说明压根没写进 ~/.composer/config.json。
项目级配置比全局更可靠，尤其在 CI/Docker 中
CI 流水线、Docker 容器、宝塔后台常以 www、runner 或非 root 用户运行，而 composer config -g 默认写入的是当前用户的 ~/.composer/config.json，权限错位时根本读不到。
推荐直接在项目根目录执行：
-
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 该命令自动向
composer.json的repositories字段追加"packagist"条目，已有私有源也不会被覆盖 - 改完后必须运行
composer update --lock，否则composer.lock里仍存着旧的dist.url，下载时先试境外地址，失败才 fallback
提交 composer.json 后，所有协作者和 CI 作业行为一致，无需额外环境准备。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
换源后仍卡在 Downloading，是因为 lock 文件和缓存没清干净
镜像只代理元数据（packages.json）和 ZIP 包分发，但 composer.lock 里记录的是旧源的 dist.url，缓存里也存着 packagist.org 的旧数据——Composer 会优先读这些，甚至根本不发请求到镜像站。
必须执行三步清理：
- 运行
composer clear-cache（不是cache-clear，已废弃） - 手动删掉
vendor/和composer.lock - 再跑
composer install --no-cache强制走新源
如果之前已改过镜像但没清缓存，还要手动清理元数据缓存目录：rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer。
Resolving dependencies 卡住跟镜像完全无关
这个阶段 Composer 在本地做 SAT 求解，完全不发网络请求，镜像再快也无济于事。常见于 composer update 卡在 “Resolving dependencies” 超过 10 秒，且日志后续无 HTTP 请求输出。
真实瓶颈通常是：
-
php.ini中memory_limit过低（默认 128M 不够），可临时设COMPOSER_MEMORY_LIMIT=-1验证 - 启用了
xdebug，关掉再试 -
composer.json里写了过宽约束，比如"*"、"^1.0 || ^2.0"或"minimum-stability": "dev"
这类问题不能靠换镜像解决，得从 PHP 环境和依赖约束本身入手。
