composer本身不支持monorepo组件独立版本控制，子包version字段被忽略，语义化版本（如^2.0）会触发远程查找而非本地加载；唯一有效写法是"@dev"、"*@dev"或"dev-main"等分支别名，版本隔离需靠git分支、ci/cd及私有仓库补位。
Composer 本身不支持 Monorepo 下的组件独立版本控制——你不能靠它自动为每个子包打 tag、发版或隔离依赖解析。所谓“独立版本”，必须靠人工约定 + 工具链补位，否则 composer install 会把所有 @dev 包当作同一快照加载，根本不存在“版本隔离”这回事。
为什么 composer require acme/logging:^2.0 不生效
现象：子包 acme/logging 的 composer.json 里写了 "version": "2.0.0"，但根项目 require 写 "acme/logging": "^2.0"，结果还是装了 dev-main 或报错找不到包。
- Composer 完全忽略子包
composer.json中的version字段——它只认远程源（Packagist / 私有仓库）发布的 tag，本地path仓库没有“版本发布”概念 -
^2.0这类语义化约束会强制 Composer 去 Packagist 查找已发布的2.x版本，而不会匹配本地path仓库；一旦没找到，就报could not find package - 唯一能触发本地加载的版本写法只有：
"@dev"、"* @dev"、"dev-main"、"dev-develop"—— 它们不是版本号，而是“分支别名”
如何让不同子包走不同开发节奏
核心思路：用分支名代替版本号，靠 CI/CD 脚本控制发布节奏，而不是指望 Composer 解析。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 每个子包维护自己的
main、stable、next分支，例如acme/logging的stable分支对应生产可用状态，next对应待集成新特性 - 根项目
require按需指定分支别名："acme/logging": "dev-stable"、"acme/http-client": "dev-next" - CI 流程中，当某子包合并到
stable分支时，自动打 tag 并推送到私有仓库（如 Satis / Private Packagist），此时才允许其他项目用"^2.0"引用已发布版本 - 开发阶段一律禁用语义化版本约束，避免误触远程源
vendor 目录里怎么区分 dev-main 和 dev-stable
不可能区分——vendor/acme/logging 就是一个符号链接，指向 packages/logging，它不记录你当初是用 dev-main 还是 dev-stable 装的。链接目标内容变了，vendor 里的软链就立刻反映变更。
- 软链目标由
repositories.url决定，和版本别名无关；dev-main和dev-stable都指向同一个物理目录 - 真要隔离，得靠 Git 分支切换：
cd packages/logging && git checkout stable，再composer update acme/logging，才能让软链指向不同提交 - 别依赖
composer show输出的 version 字段——它显示的是子包composer.json里写的值，不是实际加载的 commit hash
哪些工具能补上 Composer 缺失的能力
纯靠 Composer 永远做不到“组件独立版本控制”，必须引入外部工具链：
-
brick/composer-split：在 CI 中把子包从 monorepo 切出、重写历史、推送到独立仓库，生成真正可被^2.0引用的包 -
monorepo-builder：管理跨包依赖、生成 changelog、校验版本兼容性，但它不替代 Composer，只是前置检查 - Git hooks + 自定义脚本：比如 pre-commit 检查
packages/*/composer.json的name是否符合命名规范，防止拼写错误导致静默 fallback - 私有 Packagist 实例（如 Satis）：只有当子包真正发布后，它的
version才有意义；开发期的“版本”只是团队协作约定，不是技术事实
最易被忽略的一点：Monorepo 里的“版本控制”本质是 Git 分支与 tag 管理，不是 Composer 的责任。你写 "@dev" 时，就等于放弃了版本语义——这时候谈“独立版本控制”，其实是在谈流程设计，而不是配置技巧。
