Composer安装卡在Downloading或超时是因仍直连packagist.org，换国内镜像可提速至1–5 MB/s；config -g repo.packagist不生效主因是键名必须为repo.packagist、type值必须显式写composer、URL须HTTPS且末尾带/，三者缺一即静默回退官方源。
composer 安装卡在 Downloading 或反复超时，不是你网络差，而是它还在直连 packagist.org——物理延迟 + TLS握手慢 + CDN未缓存，导致包下载常卡在 10–30 KB/s。换国内镜像后，速度普遍升至 1–5 MB/s，耗时下降 60% 以上。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
为什么 composer config -g repo.packagist 总是不生效
这条命令静默失败率极高，但根本原因不是网络，是三个硬性条件漏掉任意一个：
- 键名必须是 repo.packagist（不能是 repos.packagist、packagist 或 repositories.packagist）
- 中间那个 composer 是 type 值，不可省；漏了就 fallback 回默认源，不报错
- URL 必须是 HTTPS 且末尾带斜杠，比如 https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会 404 或静默回退）
验证是否写入成功：运行 composer config -g repo.packagist，输出必须是完整 JSON，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或只返回字符串，说明没写进去。
宝塔、CI、计划任务里全局配置为啥不起作用
因为 composer config -g 写的是当前用户的配置文件（Linux/macOS 在 ~/.composer/config.json，Windows 在 C:\Users\用户名\AppData\Roaming\Composer\config.json），而宝塔「一键部署」、PHP 管理器、Jenkins 或 systemd 服务通常以 www、jenkins 或 runner 用户身份运行，根本读不到你 shell 里配的 root 配置。
解决方法很直接：
- 先确认实际执行用户：在宝塔终端里运行 whoami，或查计划任务日志里的 UID
- 再用对应用户执行配置：比如是 www 用户，就运行 sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- CI 脚本中不要依赖全局配置，改用临时参数：composer install -vvv --repository-url=https://mirrors.aliyun.com/composer/
项目级配置如何安全追加镜像而不删私有源
进项目根目录后执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g），这条命令的行为取决于你当前 composer.json 的 repositories 结构：
- 如果是空对象 "repositories": {}，它会自动转为标准数组并插入 packagist 条目
- 如果是数组格式 "repositories": []，它会向末尾 push 新项，不破坏已有 Git 私有源或 Satis 源
- 但如果你手动编辑 composer.json，务必确保：
• "packagist.org": false 写在根节点（不是 repositories 里面）
• "repositories" 里 packagist 条目的 type 是 "composer"，不是 "package" 或空字符串
• 改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update），否则旧 lock 文件里的 hash 可能和镜像元数据不匹配
composer update 卡在 Resolving dependencies？那和镜像无关
镜像只加速两件事：元数据拉取（如 packages.json）、tarball 下载（zip 包）。它不参与依赖解析过程。
如果 composer update 卡在 Resolving dependencies 几十秒甚至几分钟，基本可以确定是以下原因之一：
- composer.json 里写了过于宽泛的版本约束（比如 "^7.0 || ^8.0" 还混着 "dev-master"）
- 本地 PHP 版本与某些包要求冲突，触发大量回溯尝试
- 项目依赖树太深，Composer 2.9.6 虽已优化算法，但极端场景仍需时间
此时换镜像毫无帮助，应先用 composer update -vvv 观察解析路径，再收紧版本约束或升级 Composer 到最新版
真正容易被忽略的是：镜像源一旦配置错误，composer 不会报错，只会静默 fallback 回官方源——你看着命令执行成功，实际却还在慢速爬墙。
