企业内部组件库需满足三个条件才能被composer识别：根目录有含合法"name"字段的composer.json、git仓库公开可访问且打过v前缀tag、项目composer.json中配置对应repositories源；否则composer require会失败。

企业内部组件库不是“扔进 Git 仓库就完事”，而是要像维护一个 Composer 包那样被发现、安装、更新和约束——否则迟早变成没人敢动的黑盒。

如何让内部组件库支持 composer require 安装

关键不在写多少组件，而在让 Composer 能识别它。必须满足三个硬性条件：

• 组件根目录下有合法的 composer.json，且含 "name" 字段（格式必须是 vendor/package-name，比如 acme/ui-kit）
• Git 仓库公开可访问（或配置了私有 Packagist 服务），且至少打过一个带 v 前缀的 tag（如 v1.2.0）
• 项目 composer.json 中声明了对应源："repositories" 指向你的 Git 地址或私有 Packagist，类型设为 "vcs" 或 "composer"

漏掉任意一条，composer require acme/ui-kit 都会报 Could not find package。

为什么 dev-main 分支不能直接 require

Composer 默认只信任稳定版本（stable），而 dev-main 属于开发版，需显式指定版本约束：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 用 composer require acme/ui-kit:dev-main 可行，但会跳过稳定性检查，上线前容易遗漏兼容性问题
• 更稳妥的做法是：在 composer.json 的 "minimum-stability" 设为 "dev"，并加 "prefer-stable": true，兼顾灵活性与默认安全
• CI/CD 流水线中若自动发布 dev-main，务必同步触发 composer validate 和依赖冲突检测，否则下游项目 update 时可能静默降级

组件升级时如何避免下游项目崩掉

内部包不是独立系统，它的变更直接影响业务代码。核心防御点在版本语义和锁文件：

• 强制使用语义化版本（SemVer）：不兼容变更必须升 MAJOR，哪怕只是改了一个公共方法签名
• 所有业务项目必须提交 composer.lock，禁止忽略它——否则 composer update 在不同机器上可能拉到不同子版本
• 发布新版本前，在测试环境跑一次 composer update --dry-run acme/ui-kit，看是否触发其他依赖的意外升级
• 若组件含运行时配置（如模板路径、API 域名），不要硬编码在 src/ 里，改用 config/ 目录 + PackageServiceProvider 注册，方便下游覆盖

私有 Packagist 不是必需品，但没它会卡在协作效率上

纯 "vcs" 源能跑通流程，但实际团队协作中很快暴露问题：

• 每次 composer update 都要全量克隆整个 Git 仓库，组件库一过百 MB，开发者等三分钟起步
• 无法做访问审计、下载统计、版本搜索，出问题时连“谁在用哪个旧版”都查不到
• 没有自动元数据缓存，多人同时 require 同一版本时，Packagist 会反复解析 composer.json，Git 服务器压力陡增

小团队可用 satis 快速搭个静态索引；中大型团队建议上 Private Packagist 或自建 toran-proxy，重点不是功能多，而是把“组件发布”从运维操作变成研发自助动作。

真正难的从来不是怎么写一个 composer.json，而是让每个开发者心里清楚：自己发布的那个 v2.1.0，正被 17 个线上服务以何种方式引用着——这种可见性，才是内部组件库活下来的前提。