Composer多渠道包管理核心是repositories数组顺序与type声明的线性优先级控制：首个返回有效元数据的仓库被锁定，后续全跳过；私有包须用vcs/package类型并置首位，镜像源须显式声明"type":"packagist"，否则功能残缺。
Composer 多渠道包管理的核心不是“同时查多个源”，而是靠 repositories 数组顺序 + 精确 type 声明实现的线性优先级控制——顺序写错，私有包就永远装不上。
repositories 顺序决定包从哪来，不是“一起查”
Composer 对每个包只尝试一个仓库：从 repositories 数组第一个开始，逐个发请求，**第一个返回有效元数据（即能提供该包信息）的仓库就被锁定，后面全跳过**。这和 DNS 查询 fallback 类似，不是并行搜索。
- 私有包（如 GitLab 上的
my-company/utils）必须用"type": "vcs"或"type": "package"声明，并放在repositories第一位 - 如果把它放最后，同名包早被
packagist.org响应了，Composer 根本不会继续往下查 - 镜像源（如阿里云）不能只改 URL，必须显式写
"type": "packagist"，否则功能残缺、漏包
packagist 镜像必须显式声明 type，否则形同虚设
很多人把 "url": "https://packagist.org" 直接换成 "https://mirrors.aliyun.com/composer/"，却不加 "type": "packagist"，结果发现搜索变慢、包名补全失效、甚至某些包根本找不到——因为 Composer 把它当普通 "type": "composer" 源处理，跳过了 packagist 协议特有的索引逻辑。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 正确写法必须带
"type": "packagist"，且位置在私有仓之后、默认源之前 - 兜底的
{"type":"packagist","url":"https://packagist.org"}可以保留，但只要前两条能响应，它就永远不会触发 - 省略这条兜底项不危险，但删掉所有
"type": "packagist"条目会导致 Composer 退回到隐式官方源，绕过你的镜像
私有包没打 tag，版本约束就等于白写
如果你的私有仓库是 "type": "vcs"（比如 Git），而目标分支（如 main）上一个 Git tag 都没有，那么你在 composer.json 里写的 "my-company/utils": "1.2.0" 完全无效——Composer 找不到 1.2.0 这个 tag，只能 fallback 到当前 commit hash，最终锁进 composer.lock 的是类似 "reference": "a1b2c3d" 的哈希值，不是版本号。
- 所有私有包发布时必须打符合 SemVer 的 tag（如
v1.2.0），且 tag 名需与 require 中的版本字符串严格匹配 - 分支别名（如
dev-main）不参与语义化版本比较，^和~对它完全无效 - 开发阶段可用
composer require my-company/utils:dev-main --no-update先写入，但上线前务必切回稳定 tag
约束只在 update 时起作用，install 完全无视 composer.json
composer install 只读 composer.lock，里面存的是上次 update 时算出的精确版本+哈希。你改了 composer.json 里的 ^1.2 或 ~1.2.3，但没跑 composer update，部署时照样装旧版——约束根本没被重新计算。
- 改完
composer.json后，必须显式执行composer update vendor/package或composer update才会触发解析 - 线上部署应始终基于 clean
vendor/+ 完整composer.lock，避免本地残留干扰 - CI/CD 流程中，
composer install --no-dev是安全的；但若要升级，必须走composer update并提交新 lock 文件
真正容易被忽略的是：私有包的 tag 管理和 repositories 顺序是硬性前提，其他所有约束、镜像、稳定性设置都建立在这两个基础上——它们错了，后面全白调。
