无法按包区分 vendor 路径。config.vendor-dir 仅支持全局字符串值，installer-paths 仅对声明了白名单 type 的包生效，path 仓库仅适用于本地开发中的单个包软链。
config.vendor-dir 只能统一改整个 vendor 目录，不能按包区分路径
想让 monolog/monolog 装进 libs/、laravel/framework 装进 vendor-core/？不行。config.vendor-dir 是全局开关，只接受一个字符串值，比如 "third-party"，它会把所有依赖一股脑塞进那个目录。你写成对象或数组，Composer 直接忽略——这不是配置错误，是设计如此。
常见错误现象："config": {"vendor-dir": {"monolog/monolog": "libs"}}} 这种写法完全无效，composer install 仍生成默认 vendor/ 目录。
- 该配置必须写在项目根目录的
composer.json中，且仅在vendor/不存在时生效 - 改完后必须删掉现有
vendor/和composer.lock，再运行composer install -
require 'vendor/autoload.php'得同步改成新路径，否则 Class not found -
bin-dir必须显式配对，例如"bin-dir": "third-party/bin"，否则phpunit等命令找不到
installer-paths 插件只对特定 type 的包生效，普通库不支持
installer-paths 看起来像“按包指定路径”的解法，但它有硬性前提：目标包必须在自己的 composer.json 中声明 "type" 字段，且该类型被 composer/installers 插件明确支持。比如 wordpress-plugin、drupal-module、symfony-bundle（v2+）。
你 require 的 guzzlehttp/guzzle 或 symfony/http-foundation 默认是 "type": "library"，插件根本不匹配——不是配置漏了，是它们压根不在白名单里。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 必须先
composer require composer/installers:^2 - 配置必须放在根项目
composer.json的extra.installer-paths下，格式严格：{"web/wp-content/plugins/{$name}/": ["type:wordpress-plugin"]} - 匹配规则支持
type:xxx、vendor/name、vendor/*，但不支持正则或通配符混合 - 插件不会动
vendor/根目录结构，只重定向匹配到的包到指定子路径
path 类型仓库 + symlink 才能真正实现“单包本地路径映射”
如果你要调试一个正在开发的私有包（比如 acme/utils），并希望它实时反映源码修改，repositories.type: "path" 是唯一可靠方式。它不改安装位置，而是让 Composer 把指定本地目录当作包源，并默认创建符号链接。
关键点不在主项目怎么写，而在被引用包自身：acme/utils/composer.json 必须包含 "options": {"symlink": true}；否则 Composer 会 fallback 到复制文件，改源码毫无反应。
- 主项目
composer.json的repositories数组里加一条：{"type": "path", "url": "../acme-utils"}（路径必须存在且含有效composer.json） - 执行
composer require acme/utils后，vendor/acme/utils应是 -> 指向../acme-utils的软链 - Windows 用户需以管理员身份运行终端，或开启开发者模式，否则
symlink创建失败 - 验证是否生效：
ls -la vendor/acme/utils（Linux/macOS）或dir vendor\acme\utils（Windows）
COMPOSER_HOME + 全局 config.json 只影响所有项目的共享 vendor，不解决“分包路径”
设 COMPOSER_HOME=/opt/my-composer 并在其 config.json 里写 "vendor-dir": "/srv/shared-vendor"，结果是：所有项目都共用同一个 /srv/shared-vendor 目录。这解决了磁盘空间重复占用，但依然无法让 A 项目把 monolog 放 lib/、B 项目放 deps/。
这个方案本质是“集中化”，不是“差异化”。它绕过了每个项目建 vendor/ 的惯例，但没提供 per-package 控制能力。
-
COMPOSER_HOME影响的是 Composer 自身配置、缓存、全局插件位置，不是依赖安装逻辑 -
vendor-dir在全局config.json中才被读取，项目级composer.json里的同名配置会被忽略 - 若部署工具或 IDE 强依赖
vendor/这个目录名，可用ln -s /srv/shared-vendor ./vendor做兼容层 - CI 脚本中所有硬编码的
vendor/bin/路径必须同步更新为共享路径下的对应位置
vendor-dir），要么限定范围只对 CMS 插件类包生效（installer-paths），要么针对单个开发中包做软链（path 仓库）。三者逻辑完全不同，混用反而容易互相覆盖或失效。 
