必须全局配置repo.packagist并设parallel-downloads=10–15，且命令需严格满足三条件：键名为repo.packagist（非repos）、第二参数为composer、URL以https://开头且末尾带/；否则静默失效。
一劳永逸的方法不存在，但「全局配置 repo.packagist + 合理调高 parallel-downloads」能覆盖 95% 的国内慢场景——前提是命令写对、环境没被覆盖、镜像本身没同步延迟。
composer config -g repo.packagist 命令为什么总不生效
不是 Composer 没反应，是它静默失败了。三个硬性条件缺一不可：
-
repo.packagist（不是repos.packagist，多一个 s 就无效） - 第二个参数必须是
composer（这是仓库类型声明，漏掉会 fallback 到官方源） - URL 必须以
https://开头且末尾带/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌）
验证是否成功：运行 composer config -g repo.packagist，输出应为 {"type":"composer","url":"https://mirrors.aliyun.com/composer/"} 或仅该 URL 字符串。如果为空、为 null、或仍是 https://packagist.org，说明没写进去。
宝塔、CI、systemd 里还是慢，因为用户身份不一致
你在终端用 root 执行了 composer config -g，但宝塔后台、CI 脚本、systemd 服务往往以 www、git 或自定义用户运行，它们读的是各自家目录下的 ~/.composer/config.json。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在宝塔【终端】里先切到对应用户：
sudo -u www bash，再执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中不要依赖全局配置，直接加参数更可靠：
composer install --repository=https://mirrors.aliyun.com/composer/ - systemd 服务需指定
User=www并确保该用户已配好镜像，否则仍走默认源
parallel-downloads 设多少才不翻车
默认值 5 太保守，设太高又容易触发 DNS 超时或 SSL 握手失败。实测安全区间是 10–15：
- 查当前值：
composer config -g parallel-downloads - 设为 12：
composer config -g parallel-downloads 12 - 企业内网或低配 CI 机器若报
file_get_contents(): SSL operation failed，立刻降为 6 - 注意：这个参数只在 Composer 2.2+ 生效，1.x 版本设了也白搭
它只加速 tarball 下载，不影响元数据请求——所以必须和 repo.packagist 配合用才有明显效果。
有些包还是从 packagist.org 下载，这不是配置失效
Composer 会绕过镜像的几种真实情况：
- 项目
composer.json里显式写了"repositories"数组（含私有 Git 源、Satis、path 类型），且没声明"packagist": false，这时元数据仍走官方源 - 包被标记为
abandoned，Composer 会尝试回源拉取原始信息做兼容 - 新发布的 alpha/beta 版本尚未同步到镜像站（通常延迟 5–30 分钟）
- 用了
--repository参数但项目已有repositories，它会全量覆盖源列表，导致私有包找不到
排查方法：加 -vvv 运行命令，看日志里实际发起请求的域名是不是你配的镜像地址——这是唯一可信依据。
