答案：因为Composer不支持通配符语法，“myorg/*”会被JSON解析器静默忽略；私有包必须在repositories数组中显式声明完整包名或由私有源真实托管，且需按顺序精确匹配。

为什么“myorg/*”写进镜像源就失效

Composer 根本不识别 myorg/* 这种通配符写法。它只认完整包名，比如 myorg/package-a 或 myorg/package-b。你在 repositories 里写 "myorg/*": "https://pkgs.example.com/"，JSON 解析器会直接当普通字符串忽略——不是报错，是静默跳过。

所谓“按命名空间分流”，实际靠的是 repositories 数组顺序 + 精确匹配。你必须把私有源声明在前面，且每个包名都要显式列出或由私有源真实托管。

• repositories 是个数组，Composer 按顺序遍历，找到第一个含该包名的源就停，不再往后查
• 私有包必须在某个 repositories 条目中，name 字段和 require 里的包名完全一致（包括大小写）
• 如果私有源地址返回 404 或不含 packages.json，Composer 会 fallback 到下一个源，甚至最终失败

composer config --repository-url 为什么对私有包没用

composer config --repository-url 只改元数据下载入口（即 packages.json 的请求地址），但它不改变“包发现逻辑”。你 require myorg/package-a，Composer 还是拿着这个完整包名去你指定的 URL 查——如果那个地址没托管 myorg/package-a，就直接报 Could not find package myorg/package-a。

它不参与路由，也不做前缀匹配。这个命令适合换公开镜像，但对私有包无效。

Discussion Composer

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

下载

• 真正生效的方式：在 composer.json 的 repositories 字段里加一条 type=package 或 type=composer 的条目
• type=composer 的私有源，必须自己维护 packages.json，且里面要包含 myorg/package-a 的完整元数据
• 别指望用 --repository-url 绕过手动声明——这是常见误解，也是卡住最久的原因

私有包和公开镜像混用时，为什么还是走 packagist.org

只要项目 composer.json 里存在 "repositories" 字段（哪怕只是空数组 []），全局配置的 repo.packagist 就会被跳过。Composer 优先级是：项目级 repositories > 临时 --repository > 全局 repo.packagist。

更隐蔽的问题是："packagist.org": false 这种开关写在 repositories 里，会屏蔽所有 packagist 流量，但如果你没同时把私有源放进去，结果就是啥都装不上。

• 检查是否真用了项目级配置：运行 composer config --list | grep repositories，看输出里有没有 repositories 相关内容
• 确认 repositories 是对象结构（如 {"packagist": {...}, "myorg": {...}}），而不是数组；数组会覆盖默认行为，必须手动补全 packagist 条目
• 阿里云、清华等公开镜像只代理 packagist.org 的公开包，不托管私有包——私有包必须单独声明源，不能指望镜像“顺便”拉下来

怎么验证私有包源是否真被命中

别信命令是否执行成功，要看 Composer 实际发了什么请求。加 -vvv 是唯一可靠方式。

运行 composer require myorg/package-a -vvv，最后几行会打印类似 Reading packages.json from https://pkgs.example.com/packages.json 的日志。如果看到的是 packagist.org 或其他地址，说明没走对源。

• 确保私有源 URL 返回的是合法 JSON，且含 packages 字段和对应包的版本信息
• 如果私有源用的是 Nexus/Artifactory，确认其 upstream 配置指向的是当前有效的镜像地址（如 https://mirrors.aliyun.com/composer/），而非已下线的 phpcomposer.com
• 私有包若用 type: path 或 type: git，它们不走任何镜像，而是直连本地路径或 Git 服务器——这类配置会绕过所有 repositories 路由逻辑

复杂点在于：Composer 的包发现机制是静态匹配，不是动态路由。你得亲手把每个私有包“摆”进正确的源里，而不是期待它自动识别前缀。最容易被忽略的是——项目级 repositories 存在时，全局镜像自动失效，且错误不报，只默默 fallback。