Composer仓库优先级由repositories数组顺序与{"packagist.org": false}共同决定：禁用默认源后才按数组从上到下短路查找，首个匹配包即生效；该开关必须为独立对象、置于私有源之后且键名严格为"packagist.org"。
Composer 不支持“合并”多个仓库源，只支持按顺序短路查找——写错顺序或漏禁用 packagist.org，私有包大概率被跳过，且不报错、不提示。
repositories 数组顺序就是查找优先级，但仅在禁用默认源后才真正生效
很多人改了 repositories 顺序却没走私有源，根本原因是没加 {"packagist.org": false}。只要这个开关缺失，Composer 就会把官方源当作隐式兜底，排在你所有显式声明的仓库之后——哪怕你把它写在数组最前，实际查找时它仍是最后一个被检查的。
-
{"packagist.org": false}必须是repositories数组里的一个独立对象，不能嵌套进其他仓库里 - 它必须放在私有源之后、数组末尾（顺序错了会导致私有源被跳过）
- 键名必须严格为
"packagist.org"，大小写和点号都不能错 - 禁用后若还需公共包，得手动把
{"type": "composer", "url": "https://packagist.org"}显式加回数组末尾
type 字段决定 Composer 怎么“理解”你的 URL，填错就白配
type 不是可选标签，而是协议绑定：它决定了 Composer 是发 HTTP 请求查 packages.json，还是尝试 git clone，或是读取本地文件。URL 再对，type 错了就完全不走那个源。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
type: "composer"→ 指向完整索引服务（如 Satis、Private Packagist、阿里云镜像），要求根路径下有合法packages.json -
type: "vcs"→ 指向 Git/SVN/Hg 仓库地址（如https://gitlab.example.com/myorg/pkg.git），Composer 只在require中明确写了该仓库存在的包时才触发拉取 -
type: "package"→ 手动定义单个包的版本与 dist，极少用于多源场景，维护成本高 - 常见错误：把私有 Packagist 的 URL 配成
vcs，结果 Composer 尝试git clone一个 HTML 页面，报Could not find package packagist.org
私有源没命中？90% 是 packages.json 里根本没声明那个包
Composer 查源不是“有没有这个域名”，而是严格比对 vendor/name 是否出现在某个源返回的 packages.json 元数据中。查不到就跳过，不报错也不 fallback。
- 运行
curl -s https://your-private-repo/packages.json | jq '.packages["myorg/my-private-package"]'确认字段存在 - 如果是自建静态服务，确保
packages.json是顶层文件，且包含完整providers块或packages字段 - 用
composer config repositories看当前生效的源列表，确认没被全局配置覆盖 - 加
-vvv跑composer require myorg/my-private-package，看日志里是否出现你的私有 URL 的Reading composer.json of行
认证凭据严禁写进 composer.json，必须分离到 auth.json
HTTP Basic、OAuth Token、SSH 密钥等敏感信息一旦出现在 composer.json 中，极易随代码泄露。Composer 会自动读取项目根目录或全局 auth.json 中的配置，无需任何额外设置。
- 项目级认证：在项目根目录放
auth.json，内容为{"http-basic": {"your-private-repo": {"username": "...", "password": "..."}}} - 全局认证：放在
~/.composer/auth.json，但 CI 环境中建议用项目级，避免污染 - Git SSH 地址（如
git@gitlab.example.com:org/pkg.git）无需auth.json，依赖系统 SSH agent - 执行
composer install不会更新repositories配置的影响，必须跑composer update --lock或删掉composer.lock后重装
最关键的细节藏在 {"packagist.org": false} 的位置和 packages.json 的结构里——前者控制查找是否短路，后者决定“查得到”还是“查不到”，两者缺一不可。很多问题表面是配置顺序不对，实际是元数据根本没准备好。
