Composer path仓库是将本地目录作为包源的机制，适用于本地开发、多项目共享私有组件、CI构建及调试fork包等场景；需在repositories中显式配置各包路径，每个包目录须含合法composer.json且name与require严格一致。

什么是 Composer path 仓库，它适合什么场景

Composer 的 path 类型仓库本质是让 Composer 把本地文件夹当作一个可安装的包源，不走 Packagist，也不需要发布到私有 Satis/Satis-like 服务。它最常用于：

• 多个本地项目共享未开源、还在快速迭代的私有组件（比如公司内部的 common-utils、auth-sdk）
• 在 CI 中跳过远程拉取，直接绑定构建产物目录（如 dist/ 或 build/package）
• 临时调试某个 fork 后未提交 PR 的第三方包

关键点：它只在 composer.json 的 repositories 里声明路径，不会自动发现子目录里的多个包——必须为每个包单独配置一条 path 记录。

如何正确配置多个本地包的 path 仓库

错误做法是试图用通配符或 glob："../packages/*" —— Composer 不支持。必须显式列出每个包的根目录，且每个目录下要有合法的 composer.json（含 name 和 version）。

正确结构示例：

my-project/
├── composer.json
└── packages/
    ├── auth-sdk/
    │   └── composer.json   ← name: "mycompany/auth-sdk"
    ├── db-tools/
    │   └── composer.json   ← name: "mycompany/db-tools"
    └── logging-bundle/
        └── composer.json   ← name: "mycompany/logging-bundle"

对应 composer.json 的 repositories 配置：

{
  "repositories": [
    {
      "type": "path",
      "url": "../packages/auth-sdk"
    },
    {
      "type": "path",
      "url": "../packages/db-tools"
    },
    {
      "type": "path",
      "url": "../packages/logging-bundle"
    }
  ],
  "require": {
    "mycompany/auth-sdk": "dev-main",
    "mycompany/db-tools": "dev-main",
    "mycompany/logging-bundle": "dev-main"
  }
}

注意：

Discussion Composer

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

下载

• url 必须是相对路径（从当前 composer.json 所在位置算起），不能是绝对路径（Windows 下 C:/... 或 Unix 下 /home/... 会失败）
• 每个包的 name 必须全局唯一，且与 require 中的包名严格一致
• 版本号写 dev-main、dev-develop 或具体 tag 均可，但不能写 *（path 仓库不支持版本通配）

常见报错和绕不过去的坑

• [InvalidArgumentException] Package mycompany/auth-sdk not found.
  → 检查 repositories 里是否漏写了该包的 path 条目；或 url 路径拼错（比如少了个 ../）；或目标目录下没有 composer.json

• Could not parse version constraint dev-main: Invalid version string "dev-main"
  → 你用了旧版 Composer（< 2.2）；升级到 Composer 2.2+ 即可，dev-main 是标准分支别名

• 安装后代码没更新？改了本地包却 composer update 没生效？
  → 默认情况下 Composer 会缓存 path 包的 zip 归档；执行 composer update --no-cache 强制重读源码；或者删掉 vendor/mycompany/auth-sdk 再装

• Windows 下路径分隔符问题
  → 始终用正斜杠 /，即使在 Windows 上也要写 "../packages/auth-sdk"，不要用 "..\packages\auth-sdk"

批量管理几十个包时，手动维护 repositories 很痛苦。这时候建议写个脚本自动生成 JSON 片段（比如用 PHP 或 Python 遍历 packages/ 目录），再合并进主配置——但 Composer 本身不提供原生批量机制。

path 仓库和 symlink 的区别在哪

path 仓库本质是「复制」：Composer 会把整个包目录拷进 vendor/（除非加 "options": {"symlink": true}）。而纯 composer config repositories.local path ../packages/* 并不存在——config 命令只支持单条添加，且不支持通配。

如果真要软链，必须在 repositories 每条里加：

{
  "type": "path",
  "url": "../packages/auth-sdk",
  "options": {
    "symlink": true
  }
}

这样安装后 vendor/mycompany/auth-sdk 就是符号链接，改源码立刻生效。但注意：

• symlink 在 Windows（非 WSL）上需要管理员权限开启开发者模式，否则失败
• composer install --no-dev 时若某 path 包被标记为 require-dev，它仍会被 symlink，但不会出现在 autoload 中

真正麻烦的从来不是配置几行 JSON，而是当团队里有人忘了 git add 新增的 packages/foo/composer.json，或者改了 name 却没同步 require ——这类问题只能靠 pre-commit hook 检查，Composer 自己不管。