composer config -g repo.packagist 必须同时满足三个硬性条件才生效：键名必须为单数小写 repo.packagist、第三参数必须显式指定 type 值 composer、url 必须 https 且末尾带 /；任一缺失即静默回退官方源，验证需输出完整 json 对象。

composer config -g repo.packagist 必须写对三个要素，否则静默走官方源——不是没生效，是根本没被识别。

为什么 composer config -g repo.packagist 总不生效

常见现象：命令执行无报错，但 composer install 依然卡在 Downloading https://packagist.org/packages.json。根本原因不是网络差，而是配置项被 Composer 完全忽略。

• repo.packagist 键名必须是单数、全小写、不能多一个 s（repos.packagist 是无效字段）
• 第三个参数 composer 是 type 值，不是注释，漏掉就 fallback 到默认源
• URL 必须以 https:// 开头，且末尾带 /（https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌）

验证是否写入成功，唯一方式是运行：composer config -g repo.packagist。输出必须是完整 JSON 对象，例如：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或报错，说明没配对。

全局配置 vs 项目级配置：哪个更稳

全局配置看着省事，但在 CI/CD、Docker 构建、宝塔面板或多人协作中极易出问题——镜像不一致会导致 composer.lock 的 hash 不同，部署失败。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 全局配置写入 ~/.config/composer/config.json（Linux/macOS）或 %USERPROFILE%\AppData\Roaming\Composer\config.json（Windows），但 CI 流水线可能以 www 或 root 用户运行，需用 sudo -u www composer config -g 显式指定用户
• 项目级配置写进 composer.json 的 "repositories" 字段，会被 Git 跟踪，新人拉代码后行为一致，且优先级高于全局配置
• 安全追加方式：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g），它会自动合并，不会覆盖已有私有源——前提是原 "repositories" 是对象，不是数组

换源后仍卡在 packagist.org？关键排查点

日志里还出现 packagist.org，说明镜像根本没走通。别急着重试，先确认三件事：

• 运行 composer diagnose，检查 secure-http: OK 和 signature verification: OK；若后者为 disabled，说明镜像跳过了签名校验，存在风险
• 删掉 vendor/ 和 composer.lock，再跑 composer install --no-cache -vvv，观察日志里真实请求的 URL 是否含国内域名
• 某些镜像（如清华源）强制要求 secure-http true，否则 HTTPS 证书校验失败；华为云镜像路径必须是 https://mirrors.huaweicloud.com/repository/php/composer/，少 /repository/php/ 就 404

composer update 卡在 Resolving dependencies？和镜像无关

镜像只加速下载（dist 包 ZIP），不解决依赖解析慢的问题。如果你发现 composer update 长时间停在 Resolving dependencies through SAT，基本可以确定是以下原因：

• composer.json 中约束太松（比如 "^1.0" 或 "*"），导致 SAT 求解器穷举组合
• 本地 PHP 版本或扩展缺失（如 openssl、curl 版本过低），引发 HTTPS 握手失败，表现为“超时”
• 启用了 classmap-authoritative（Composer 3.x 默认开启），每次 update 都强制重扫整个 vendor 目录；可临时关闭：composer config authorative false

最常被忽略的一点：项目 composer.json 里若已定义 "repositories": [] 或 "packagist.org": false，全局镜像会被直接跳过——这种情况下，必须在项目级显式启用 "packagist" 子项。