composer require 不受全局镜像影响，因其仅通过镜像获取元数据，下载 ZIP 仍直连 GitHub 等原始 dist.url；需删 composer.lock、用 --repository 指向支持 ZIP 代理的源（如 ghproxy.com）或部署私有仓库才能真正加速。

composer require 为什么不受全局镜像配置影响

因为 composer require 默认不读取 repo.packagist 镜像配置，它只在解析依赖时走 packagist.org 元数据，下载阶段仍直连 GitHub —— 这是 Composer 2.2+ 的行为变更，不是 bug，而是设计逻辑。你配了阿里云镜像、清了缓存、composer install -vvv 看到 mirrors.aliyun.com，但 composer require foo/bar 依然卡在 Downloading https://codeload.github.com/...，很正常。

• composer require 本质是「先解析 + 再安装」两步合并：它会临时拉取元数据（此时可能走镜像），但一旦确定要装哪个版本，就直接按 composer.lock 或包自身 dist.url 下载 ZIP，完全绕过你设的 repo.packagist
• 如果你项目已有 composer.lock，require 会复用其中记录的 dist.url，哪怕这个 URL 是 https://api.github.com/，它也不会替换成镜像地址
• 没 lock 文件时，require 会查 packagist 元数据，但下载环节仍用包注册的原始 dist 地址——镜像源不托管 ZIP，只提供 JSON 列表

如何让 composer require 真正走镜像加速

唯一可靠方式是强制指定仓库，并确保该仓库能提供 ZIP 包下载路径。阿里云等公共镜像不代理 ZIP，所以必须换思路：

• 加 --repository 参数并指向支持完整代理的服务，例如 ghproxy.com：
  composer require monolog/monolog --repository=https://ghproxy.com/https://github.com/Seldaek/monolog
• 在项目 composer.json 中为特定包显式写死 dist：
  

  "repositories": [
    {
      "type": "package",
      "package": {
        "name": "monolog/monolog",
        "version": "3.0.0",
        "dist": {
          "url": "https://ghproxy.com/https://github.com/Seldaek/monolog/archive/refs/tags/3.0.0.zip",
          "type": "zip"
        }
      }
    }
  ]

• 企业用户建议部署 satis 或 toran proxy，把 GitHub ZIP 缓存到内网，再配置 repo.packagist 指向它——这时 require 才真正受益

为什么 --repository-url 对 composer require 无效

因为参数名错了：--repository-url 不是 Composer 官方支持的选项，正确的是 --repository，且必须带完整 URL（含协议和路径）。更关键的是，即使写对，它也只影响元数据获取环节，对已存在的 composer.lock 或包注册的原始 dist.url 无任何覆盖能力。

Discussion Composer

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

下载

• 执行 composer require foo/bar --repository=https://mirrors.aliyun.com/composer/ 后，日志里会出现 Loading composer repositories 来自阿里云，但紧接着还是 Downloading https://codeload.github.com/...
• 这是因为 --repository 只改了「找包信息」这一步，而「下 ZIP」这一步由 lock 文件或包自身定义决定，Composer 不做二次映射
• 想验证是否生效，必须删掉 composer.lock 并确保项目里没写死 repositories，否则优先级顺序会让命令行参数被忽略

容易被忽略的细节：require 和 install 的镜像生效边界

很多人以为配完镜像就一劳永逸，但 require 和 install 的生效路径完全不同。最常踩的坑是：在 CI 脚本里用 composer require 装包，却指望全局镜像自动加速——结果超时失败。

• composer install 严格按 composer.lock 执行，只要 lock 里 dist URL 是 GitHub 地址，哪怕你配了镜像，它照样直连；只有删 lock 后重装，才可能触发镜像元数据查询
• composer require 不生成 lock 就直接装，所以它更“裸”，更容易暴露 ZIP 下载瓶颈
• 真正能统一加速的，只有私有仓库方案（如 satis）或反向代理方案（如 ghproxy），它们改的是 ZIP 的实际请求目标，而不是元数据源

别指望一条 config -g 命令解决所有场景。镜像配置只是半程加速，ZIP 下载那一步，得靠你自己补上代理层或换源策略。