non-feature-branches 并非 composer 的配置项，而是对 packagist 分支索引逻辑的误称；composer 只认 git tag 作为正式版本，dev-main 等为开发分支别名，稳定安装需靠 minimum-stability、prefer-stable 和规范版本约束协同控制。
什么是 non-feature-branches？它不是 Composer 的配置项
Composer 本身**没有 non-feature-branches 这个配置或概念**，它不属于 composer.json、config、repositories 或任何官方字段。你看到这个词，大概率是来自某篇过时/误译的中文教程，混淆了 Packagist 的包索引逻辑或 VCS（如 Git）分支策略与 Composer 行为的关系。
真正起作用的是：version 字段的写法、require 中的版本约束（如 "monolog/monolog": "^2.0"），以及 Packagist 如何从 Git 分支打标签（tag）并映射为稳定版本。
- Composer 只认 Git 的 tag（如
v2.10.0）作为正式版本；dev-main、dev-develop这类才是“开发分支”别名 - 所谓 “non-feature-branches”，实际想表达的可能是：不希望 Composer 自动拉取
dev-开头的不稳定分支，只接受带语义化版本号的 tag - 如果你在
composer.json里硬加了"non-feature-branches": false—— 这行会直接被忽略，不报错也不生效
怎么让 Composer 只装稳定版，避开 dev 分支？
靠约束版本写法 + 启用稳定模式（minimum-stability）+ 显式禁用 prefer-stable 风险项，三者配合才真正有效。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"minimum-stability": "stable"：全局开关，告诉 Composer 默认只考虑stable、RC、beta等标记的版本（按稳定性排序），dev-分支默认被排除 -
"prefer-stable": true：在满足require版本范围的前提下，优先选 stable 而非同范围内的 dev 版本（比如"^2.0"同时匹配v2.9.0和dev-main，开启后选前者） - 避免在
require中写死"dev-main"或"dev-develop"—— 这等于主动绕过所有稳定性控制 - 如果依赖的包没打 tag，只有分支，Packagist 不会将其列为“稳定可用包”，Composer 默认根本搜不到它（除非你手动加
vcsrepository）
为什么有时还是装了 dev 分支？常见漏点
不是 Composer 失控，而是某些隐式行为或本地配置悄悄覆盖了你的稳定策略。
-
composer update时加了--with-all-dependencies或--with-dependencies，可能把子依赖的dev-版本也拉进来 - 项目根目录存在
composer.lock，而它记录的是上次安装时的dev-分支引用（比如"source": {"type": "git", "url": "...", "reference": "abc123..."}），composer install会照单全收，完全不检查稳定性 - 运行过
composer require vendor/package:dev-main并提交了 lock 文件，后续没人手动改require行，就一直卡在 dev 上 - 公司私有 Packagist（如 Satis / Private Packagist）配置了 “自动同步所有分支”，且未过滤掉
dev-命名分支，导致它们出现在可安装列表中
验证当前装的是不是稳定版？快速检查法
别只看 composer show vendor/package 输出的 version 字段 —— 它可能显示 dev-main，但来源未必是分支。
- 执行
composer show -s vendor/package（-s表示显示 source 信息），重点看source下的reference是否对应某个 tag（如v3.5.2）还是 commit hash（暗示是分支快照） - 查
vendor/composer/installed.json，搜索该包，看"version_normalized"字段：稳定版是"3.5.2.0"，dev 分支是类似"9999999-dev"的伪版本 - 用
git ls-remote --tags https://github.com/vendor/repo.git对比远程 tag 列表，确认本地装的 reference 是否有对应 tag
最易被忽略的一点：即使你写了 "minimum-stability": "stable"，只要某条 require 显式写了 "dev-main as 3.0.0"，Composer 就会照做 —— 它的优先级高于全局 stability 设置。
