path仓库仅限本地开发，ci/cd中因路径不存在而失败；vcs仓库跨环境可靠，需显式require触发拉取；二者不可混用同名包，开发用path，交付用vcs。
Path仓库只在本地开发阶段有效，CI/CD里基本会挂
Path仓库本质是“绕过网络、直连文件系统”，所以它依赖本地目录真实存在、路径可读、大小写精确匹配。CI/CD环境（比如 GitHub Actions、GitLab CI）通常不带你的本地 ../packages/my-utils 目录，composer install 会直接报 Source path "../packages/my-utils" does not exist。这不是配置错，是设计如此。
它适合：快速验证包接口、调试 autoload、配合 IDE 实时跳转；不适合：构建镜像、部署上线、团队共享稳定依赖。
- 必须用相对路径，
url不能以/或C:/开头 - 目标目录下必须有合法的
composer.json，且name字段要和require中完全一致（包括 vendor 名） - 默认创建符号链接，但 Windows 或某些容器里可能失败，可加
"options": { "symlink": false }强制复制
VCS仓库能跨环境拉取，但 require 时必须显式触发
VCS仓库（"type": "vcs"）把 Git/SVN 地址当源，Composer 不会主动去它那儿查包列表——只有你执行 composer require vendor/name 或 composer update vendor/name 时，才会按 repositories 里的 VCS 配置去克隆代码。它不参与全局元数据匹配，所以不会和 Packagist 镜像抢顺序，也不会被 {"packagist.org": false} 影响。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- URL 可以是
git@github.com:org/pkg.git或https://gitlab.example.com/group/pkg.git - 分支名、tag、commit hash 都支持，版本约束写在
require里，比如"vendor/name": "dev-main" - 私有 Git 需提前配好 SSH key 或 token，否则
composer update会卡在认证环节
别混用 Path 和 VCS 同名包，否则行为不可控
如果 repositories 里同时声明了 Path 和 VCS 两种方式指向同一个 vendor/name，Composer 的行为取决于 repositories 数组顺序 + 当前命令类型：用 install 时走 Path（只要路径存在），用 require vendor/name 时可能走 VCS；更麻烦的是，composer update 可能先拉 VCS 再覆盖 Path 的修改，导致本地调试失效。
- 开发阶段优先用 Path，上线前统一切到 VCS，并删掉 Path 配置
- 不要在
composer.json里保留已停用的仓库项，它们仍会影响解析逻辑 - 运行
composer config repositories确认当前生效顺序，别信注释或记忆
选哪个？看阶段、看协作、看交付物
Path 是临时胶水，VCS 是交付契约。你在改包代码、测接口、调 IDE 跳转，就用 Path；你要让同事、CI、生产环境都装得一致，就必须用 VCS（或私有 Packagist）。Path 的路径校验松散、静默失败多；VCS 的克隆过程透明、日志明确、可审计。
最容易被忽略的一点：Path 仓库的 version 字段如果写死（比如 "version": "1.0.0"），而本地代码改了但没改 version，composer update 就不会刷新链接——它只比对 version，不比对文件内容。
