composer config -g repo.packagist 必须严格满足三条件才生效：键名必须为单数 repo.packagist（非 repos），第二参数必填 composer（声明类型），URL 必须以 / 结尾（如 https://mirrors.aliyun.com/composer/）；任一错误即静默回退至 packagist.org。
composer config -g repo.packagist 这条命令必须正确执行，否则你依然在默默连接 packagist.org，下载慢、超时、404 都不是网络问题，而是镜像根本没生效。
为什么 composer config -g repo.packagist 总是不生效？
90% 的失败不是因为网络差，而是命令写错三个硬性条件：
-
repo.packagist不能写成repos.packagist（多一个s就静默忽略） - 第二个参数必须是
composer（这是仓库类型声明，漏掉就 fallback 到官方源） - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会导致路径拼成/composerpackages.json，直接 404）
验证是否写入成功：运行 composer config -g repo.packagist，输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或至少是完整 URL 字符串。如果返回空、null 或仍是 https://packagist.org，说明配置未落进实际运行环境。
项目里已有 composer.json，全局镜像还管用吗？
不管用。Composer 的源优先级是：项目级 repositories > 全局配置 > 默认源。只要项目根目录的 composer.json 含有 "repositories" 字段（哪怕只是空数组 []），全局设置就完全失效。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 检查方式：
composer config repo.packagist（无-g）——如果有输出，说明项目级已覆盖 - 安全追加而非覆盖：手动编辑
composer.json，在"repositories"数组首位插入：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"} - 千万别在
repositories内部写"packagist.org": false，这会彻底关掉基础包来源；如需禁用默认源，应放在composer.json根节点，且仅当明确需要兜底策略时才启用
CI/CD 或宝塔面板里换源后还是慢？查用户身份
终端里执行成功 ≠ 宝塔后台或 CI 流水线里生效。它们往往以不同用户身份运行（如 www、runner、root），而 composer config -g 默认只写当前登录用户的 ~/.composer/config.json。
- 宝塔中 PHP 管理器通常用
www用户执行，需先切到该用户：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本中避免
sudo composer config -g（可能写进root配置），改用临时参数更可靠：composer install --repository=https://mirrors.aliyun.com/composer/ - 验证真实请求地址：加
-vvv运行命令，搜索日志里的GET行，确认域名是镜像站地址（如mirrors.aliyun.com），而不是packagist.org或 GitHub
换源后 composer install 报 hash 不匹配或卡在 Resolving dependencies？
这是常见但可预期的行为，不是配置失败。
- 已有
composer.lock时首次切换镜像，大概率因元数据解析差异触发 hash 校验失败——删掉vendor/和composer.lock，再执行composer install即可 - 卡在
Resolving dependencies通常和镜像无关，而是依赖图本身复杂或含大量dev版本约束；建议清理"minimum-stability": "dev"类配置，改用稳定版本 - 缓存路径别搞错：应缓存
~/.composer/cache，而非vendor/；后者与 PHP 版本、扩展强耦合，缓存错环境会导致Class not found
packages.json），但 zip 包仍可能从 GitHub 或 GitLab 直接下载——尤其当包的 composer.json 显式写了 dist.url。这种情况下，-vvv 日志里能看到混合域名请求，得靠 --prefer-dist 强制走分发包，或联系包作者修正 dist 配置。 
