path仓库仅适用于本地开发联调，上线前必须移除；其本质是让composer将本地目录当作包源，不联网、不打包、不校验签名，纯文件系统映射，依赖合法composer.json及name与require完全一致、相对路径配置，且ci环境下因路径缺失易静默失败。
path仓库只适合本地开发联调，上线前必须移除
path仓库本质是让Composer把本地目录当包源用，不走网络、不打包、不校验签名，纯文件系统映射。它只该出现在你写代码时还没提交到Git的阶段。
- 本地包目录里必须有合法
composer.json，且name字段要和require中写的完全一致（比如"acme/utils"） -
url必须是相对路径（如"./packages/utils"），不能带file://，也不能用绝对路径（/home/xxx或C:\xxx在CI里大概率静默失败） - 一旦你运行
composer install，Composer会直接把那个目录软链接进vendor——所以CI构建时如果没同步该目录，就会报Could not find package，但不提示原因
VCS仓库用于稳定分支协作，但必须严格对齐name和版本
VCS类型（"type": "vcs"）才是生产环境该用的方式，它让Composer去克隆Git仓库并解析其中的composer.json。但它不是“自动识别URL里的包名”，而是死认name字段。
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 你在
repositories里写的url可以是https://gitlab.com/acme/utils.git，但包能不能装上，只取决于这个仓库根目录下composer.json里的"name": "acme/utils"是否和require中的一模一样 - 分支名必须显式声明为版本约束：如果目标分支叫
main，就得写"acme/utils": "dev-main"；如果composer.json里写了"version": "1.2.0"，那就要用"^1.2"这类语义化版本 - GitLab/GitHub/Bitbucket三者认证方式不同：
auth.json里http-basic对应GitLab，github-oauth对应GitHub，bitbucket-oauth不存在——Bitbucket必须用App Password配http-basic
别混用path和VCS指向同一个包名
如果你在repositories里同时声明了path和vcs两种类型，且都指向acme/utils，Composer会优先采用path——哪怕你删了本地目录，它也不会 fallback 到Git，而是直接报错。
- 这种配置在团队协作中极其危险：你本地能跑，CI却失败，因为CI没你的
./packages/utils - 更隐蔽的问题是
composer update行为不一致：path仓库不会触发Git拉取，也不会更新composer.lock里的commit hash，导致版本锁定失效 - 真正需要多源路由时，应该用
"type": "package"手动声明元数据，或者靠repositories数组顺序控制优先级（靠前的先匹配）
选错类型会导致CI构建不可重现
这是最容易被忽略的点：path仓库的路径是开发者本地环境决定的，而VCS仓库的commit hash是Git历史决定的。前者无法纳入版本控制，后者可以。
- 如果你用path做日常开发，又没在上线前切换成VCS，
composer.lock里记录的会是本地文件路径的哈希，而不是Git commit —— 这意味着别人composer install根本还原不出同样结构 - 某些CI平台（如GitLab CI）默认清空工作区，
./packages/utils根本不存在，path仓库直接跳过，不报错也不警告，最后vendor里缺包，运行时报Class not found - 正确节奏是：开发初期用path快速迭代 → 功能稳定后推送到Git → 改
repositories为vcs →composer update acme/utils锁死commit → 提交composer.lock
