Composer不按require顺序决定版本，而是用SAT求解器统一处理require、conflict等所有约束；二者是并列逻辑条件，共同筛选可行解，无优先级之分。
Composer 不会按 require 顺序或书写位置决定哪个版本“赢”，它用 SAT 求解器统一处理所有约束——require、conflict、replace、PHP 版本、稳定性标记全部参与逻辑合取。所谓“覆盖”，其实是多个约束共同筛选后只剩一个可行解，或根本无解而报错。
为什么私有包总被 packagist.org 覆盖？
根本原因不是版本低，而是仓库查找顺序 + 隐式兜底机制共同作用的结果：
-
repositories数组从上到下扫描，第一个返回元数据的仓库即被采用，后续仓库完全不查 -
packagist.org是隐式存在的，且默认排在所有显式仓库之后——哪怕你没写它，它也在最后兜底 - 如果你把私有仓库放在数组末尾，又没加
{"packagist.org": false}，Composer 就会先命中 packagist 上的同名包，私有仓库根本没机会响应 - 用
"type": "vcs"声明 Git 仓库时，若 URL 末尾带.git（如https://git.example.com/my/pkg.git），某些 Composer 版本会解析失败，导致该仓库被跳过
如何让私有包真正优先？
关键不是“放前面”，而是“类型正确 + 显式排除 + 精确声明”：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 私有包必须用
"type": "package"显式声明，包含完整name、version、dist字段；否则 Composer 会忽略它 - 若用
"type": "vcs"，确保 URL 是纯 HTTPS 地址（不含.git后缀），且该仓库只提供你要 override 的包（否则可能意外覆盖其他公共包） - 在
repositories数组开头放私有源，末尾显式补上{"packagist.org": true}或镜像地址；若想彻底禁用官方源，必须同时关掉并手动补上镜像：先composer config repo.packagist false，再composer config repositories.aliyun composer https://mirrors.aliyun.com/composer/ - 避免多个
vcs类型仓库声明同一name，Composer 只取第一个匹配项，第二个静默丢弃
require 和 conflict 真的能互相“压制”吗？
不能。它们不是先后执行的指令，而是同时生效的布尔子句：
-
"require": {"monolog/monolog": "^2.0"}和"conflict": {"monolog/monolog": " 共同限定最终版本必须满足 <code>>=2.0.0 && =2.9.0，交集是2.9.0–2.99.99 - 如果某个间接依赖（比如你没直接 require 的
guzzlehttp/guzzle）要求"monolog/monolog": "^1.0"，而你的conflict又排除了所有 1.x，那整个求解就失败，报Your requirements could not be resolved -
conflict是全局生效的：哪怕你本地没require某个包，只要它的版本被任何依赖链拉进来，就会触发冲突 - 别用
conflict当提醒——那是文档和 CI 检查的事；它只该用于强互斥场景（如两个包实现同一接口但 ABI 不兼容）
dev 分支、别名和 commit hash 怎么锁住？
写 "my/private": "dev-main" 等于放弃锁定——main 分支随时变，composer.lock 里存的只是当前 commit hash，下次 update 就可能切走：
- 给私有包打语义化 tag（如
v1.2.0），然后require写"my/private": "^1.2"，配合vcs仓库声明 - 必须用分支时，至少固定到 commit：
"my/private": "dev-main#abc1234"，这样composer.lock才能记录具体 SHA 并复现 - 别依赖
as别名来“覆盖”版本逻辑——它只影响 autoload 和版本解析映射，不阻止 Composer 拉新 commit 或更新 tag - 国内镜像（如阿里云）通常不同步
dev-分支，所以即使你写了dev-main，也大概率 fallback 到 packagist.org 查，而它又不抓 dev 分支 → 最终报Package not found
最常被忽略的一点：当你改了 repositories 顺序或开关，却没删 composer.lock 重装，Composer 仍会沿用 lock 文件里旧的来源记录——它不会自动刷新元数据来源。要验证是否生效，得删 lock、清 vendor、跑一次干净的 composer install。
