Composer镜像未加速是因为composer config -g repo.packagist未生效，必须同时满足三条件：键名严格为repo.packagist（单数）、第二参数显式写composer、URL须HTTPS且末尾带/；任一缺失即静默回退官方源，验证需输出完整JSON如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer config -g repo.packagist 为什么导出没加速
导出（composer install 或 composer update）卡在 Loading composer repositories 或反复请求 packages.json，不是网络慢，是镜像根本没接管元数据源。这条命令必须同时满足三个硬条件才生效：repo.packagist（单数、全小写）、中间显式写 composer（type 值）、URL 必须以 https:// 开头且末尾带 /。漏一个就静默回退到 packagist.org，连 warning 都不报。
验证是否真生效，只看这一条命令输出：
composer config -g repo.packagist
正确结果必须是完整 JSON 对象，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
如果输出为空、null、报错，或仍是 https://packagist.org，说明配置失败。别信“我执行过了”，要亲眼看到这个输出。
导出时 dist.zip 仍从 GitHub 下载怎么办
镜像只代理元数据（packages.json），不托管实际 ZIP 包；composer.lock 里存的 dist.url 是原始地址（如 https://codeload.github.com/...）。换镜像后不清理旧锁文件，导出永远走 GitHub。
- 必须删掉
composer.lock和vendor/ - 运行
composer clear-cache，否则缓存里的旧元数据会干扰重试 - 再执行
composer install，让 Composer 重新拉取镜像源的packages.json并生成新dist.url - 若 CI 中缓存了旧
composer.lock，需在脚本开头加rm composer.lock
注意：--repository 参数对已有 composer.lock 完全无效——它只影响元数据拉取环节，不改已写死的 dist 地址。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
Mac / 宝塔 / CI 环境下导出加速总失效
全局配置写在 ~/.composer/config.json，但不同执行主体读的是不同用户的家目录：
- 你在终端用
sudo composer config -g→ 写入/root/.composer/config.json - 宝塔后台、PHP-FPM 进程默认以
www用户运行，根本不会读/root/下的配置 - Docker 构建中多个 job 并发执行
composer config -g，可能互相覆盖/root/.composer/config.json - CI（如 GitHub Actions）常以
runner用户运行，root下写的配置不生效
解决办法：切到对应用户下执行，例如：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
或者更稳妥的做法：进项目根目录，用项目级配置（不加 -g）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动 merge 到 composer.json 的 repositories 字段，不破坏已有私有源。
导出加速后仍卡在 Resolving dependencies
这个阶段不走网络，但极度依赖 PHP 运行环境：
-
memory_limit太低（如 128M）会导致依赖图解析失败重试 —— 临时设COMPOSER_MEMORY_LIMIT=-1 - 启用了
xdebug（php -v可确认），会让解析慢 5–10 倍 —— 用php -d xdebug.mode=off $(which composer) install临时禁用 -
"platform"配置与当前 PHP 版本不匹配（如"php": "7.4"却在 PHP 8.2 上跑），触发大量降级查找 -
composer.lock里残留已下线包的引用，导致回退搜索 —— 删 lock + vendor 后重装
并发下载数也要调对：新版 Composer 只认 http-max-concurrent-downloads，parallel-downloads 已弃用。设成 10 是合理上限，再高反而容易触发限流或 TLS 握手失败。
