必须设置 minimum-stability: dev 才能安装 dev-main 等开发分支，同时需确认远程仓库存在该分支，并提交更新后的 composer.lock 文件以确保部署一致性。
直接装 dev-main 或 dev-develop 会失败，因为 Composer 默认不启用不稳定版本
Composer 默认只允许安装 stable 版本（即带明确版本号如 2.5.0 的发布版），dev- 开头的开发分支被视为 dev 稳定性级别，不在默认白名单里。直接运行 composer require vendor/package:dev-main 很可能报错：Your requirements could not be resolved to an installable set of packages.
- 必须显式声明允许的最小稳定性 —— 不是改包版本，而是告诉 Composer「我接受不稳定代码」
- 这个设置作用于整个项目，不是单条命令；改了
composer.json才真正生效 - 别用
--stability=dev临时参数：它只影响当前命令，且不能覆盖composer.json中已设的更严格限制
composer.json 里加 "minimum-stability": "dev" 是最常用解法
这是让 dev-main、dev-develop 能被识别和安装的必要前提。但要注意它会影响所有依赖，不只是你想要的那个包。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 在
composer.json根对象下添加："minimum-stability": "dev"，同时建议加上"prefer-stable": true，避免意外装到其他包的dev版本 - 如果只想对某个包开绿灯，用
require时指定完整约束："vendor/package": "dev-main as 999.999.999"，其中as后的伪版本号是为了绕过稳定性检查，不是真实版本 - 执行
composer update vendor/package（不是install）才能触发重新解析，尤其当你之前已锁定了稳定版
用 dev- 分支名前要确认远程仓库真有这个分支
很多人输完命令发现还是装不上，其实是因为目标仓库压根没有 dev-main 或 dev-develop 分支 —— Composer 不会自动 fallback 到最近分支，它严格按字面匹配 Git 分支名。
- 先去 GitHub/GitLab 页面看一眼仓库的
Branches标签页，或运行git ls-remote --heads https://github.com/vendor/package.git查实际分支名 - 常见分支名包括：
main、master、develop、next，对应 Composer 写法是dev-main、dev-master、dev-develop - 如果作者用的是
trunk或release/3.x这类非标准名，就得写成dev-trunk或dev-release/3.x，斜杠要保留
装完记得检查 composer.lock 里的 source 类型和 reference
成功安装 dev- 版本后，composer.lock 里对应包的 source 字段会是 "type": "git"，且 reference 是真实 commit hash，不是 tag 名。这点很关键，关系到部署可重现性。
- 如果你 CI/CD 流程依赖
composer install（不走update），那 lock 文件必须提交进 Git，否则下次拉代码就可能装回稳定版 - 别手动改
lock文件里的reference：Composer 不认，下次update会被覆盖 - 想锁定到某个具体 commit？用
dev-main#abc1234语法，Composer 会把它解析为分支 + 提交哈希，比纯dev-main更可靠
dev- 版本从来不是改个版本号就完事的事，它牵扯到稳定性策略、分支存在性、lock 文件机制三层校验。最容易漏掉的是没确认分支名是否真实存在，以及忘了把更新后的 composer.lock 提交进仓库。 
