必须用dev-分支名语法+显式声明repositories，否则composer默认只查packagist；分支含斜杠需写成dev-release/2.4.x，ci需确保仓库可访问且satis已同步元数据。
直接用 composer require vendor/package:dev-branch-name 就能装，不需要改 composer.json，也不需要提前声明仓库——前提是包在 Packagist 上有注册，且分支存在。
为什么 composer require 能直接装分支，但 composer install 不行
因为 composer install 只读 composer.lock，它不管分支名有没有更新；而 composer require 会触发一次 update 流程，强制解析新版本约束并拉取最新提交。
-
composer install是“按锁安装”，哪怕远程分支已推进几十次，本地仍锁定在composer.lock里记录的那个 commit -
composer require vendor/package:dev-main会重写require字段、更新依赖树、重新 resolve 版本，并把新分支的 HEAD 写进composer.lock - 如果只是想临时切分支测试，别碰
composer.json，就用require命令来回切换，比如composer require vendor/package:dev-staging
dev-* 分支名必须严格匹配 Git 仓库里的实际分支名
Composer 不会自动映射别名，dev-feature/login 和 dev-feature-login 是两个完全不同的版本约束，后者根本不存在。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 分支含斜杠（如
release/2.4）必须写成dev-release/2.4，不能省略dev-，也不能替换成下划线或短横 - GitHub 新仓库默认主分支是
main，不是master，所以优先试dev-main，而不是盲目用dev-master - 私有仓库（如 GitLab）若用 SSH 地址（
git@gitlab.com:org/pkg.git），需确保本地已配好 SSH key，否则require会卡在认证环节，无明确错误提示
装不上时，90% 是 minimum-stability 拦住了
默认 minimum-stability 是 stable，而 dev-* 属于开发版，会被直接过滤掉，报错通常是 Could not find a version of package ... matching your minimum-stability。
- 临时解决：加
@dev后缀，例如composer require vendor/package:dev-main@dev - 长期解决：在
composer.json里显式设"minimum-stability": "dev"，但要注意这会影响所有包，可能拉到不稳定的依赖 - 更稳妥的做法是只给特定包放宽，即用
@dev，不改全局策略
想锁定到某个具体 commit，而不是分支最新提交
分支名只是指针，随时会变；要精确控制，得用 dev-branch#commit-hash 格式，且必须配合 vcs 类型仓库声明。
- 仅写
dev-main#abc123不生效——Composer 不知道去哪找这个 commit，必须先在repositories里声明 Git 地址 -
repositories中的url必须是完整可克隆地址（https://或git@），不能是file://或相对路径 - commit hash 必须存在于该分支上，且大小写敏感；如果远程已删掉该 commit（比如 force push 覆盖），
composer update会失败
最易被忽略的一点：即使你写了 dev-main#abc123，composer update 也不会自动 fetch 远程新 commit —— 它只校验本地 composer.lock 里存的 hash 是否还在本地 repo 的 reflog 里。真要更新，得先 git pull 或 git fetch 把远端变更同步下来。
