Composer不支持真正意义上的全局依赖目录，因其自动加载器基于项目composer.json生成，硬链接外部vendor会导致autoload失效、版本冲突及CI失败；path仓库才是正解，通过本地路径声明+符号链接实现安全共享。
composer 不支持真正意义上的“全局依赖目录”，所谓“全局链接”在开发环境中容易误用、不可靠，且与 Composer 的设计哲学相悖。它不会像 npm -g 或 pip install --user 那样提供一个跨项目的统一 vendor。强行模拟全局共享，大概率导致 autoload 失效、版本冲突或 CI 失败。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
为什么不能直接用 symlink 指向一个公共 vendor 目录
Composer 的自动加载器（vendor/autoload.php）是基于当前项目 composer.json 生成的，硬链接到外部 vendor 后：
- autoload 映射仍指向原项目路径，类找不到
- composer dump-autoload 不会重新扫描外部目录结构
- composer update 会清空并重建当前 vendor，覆盖你的 symlink
- IDE（如 PHPStorm）无法正确解析命名空间引用，跳转和补全失效
- 多个项目 require 同一包的不同版本时，物理共用 vendor 会直接冲突
path 类型仓库才是开发环境下的正解
它不共享 vendor，而是让多个项目“按需链接”同一份源码，且由 Composer 完全管理生命周期。
关键点：
- 共享代码必须是一个独立包，含合法 composer.json（含 "name"、"autoload"）
- 主项目通过 "repositories" 声明该本地路径为 type: "path" 仓库
- require 时指定 dev 分支或 -dev 版本（如 "acme/utils": "dev-main"）
- 默认启用 "symlink": true（无需额外配置，Composer 2.2+ 自动生效）
- 运行 composer update acme/utils 后，vendor/acme/utils 就是源码目录的符号链接
如何避免团队协作时路径失效
相对路径比绝对路径更可靠，但仍有前提：
- 把共享库放在项目根目录的同级位置（如 ../shared-utils），主项目中写 "url": "../shared-utils"
- 若路径不一致，可用环境变量：在 composer.json 中写 "url": "${HOME}/code/shared-utils"，并确保所有成员已设置 HOME
- 绝对禁止把 path 仓库配置成 /var/www/shared 这类机器强相关路径
- 提交 composer.json 和 composer.lock，但不要提交 vendor/；CI 环境需提前同步好共享库源码目录
- 若某成员缺失该路径，composer install 会明确报错 Source directory ... does not exist，而不是静默失败
别碰全局 config.json 里的 repositories
有人试图在 ~/.composer/config.json 里加 repositories 来“一劳永逸”，这会导致：
- 该配置对所有项目生效，无法区分 A 项目用内网源、B 项目必须走 Packagist
- CI 流水线（如 GitHub Actions）默认无此配置，构建必然失败
- Git 无法追踪变更，团队成员配置不同步，composer.lock 生成结果不一致
- composer prohibits 等诊断命令可能因源顺序异常而漏报冲突
实际开发中，最常被忽略的是：共享包的 autoload 必须正确声明命名空间与路径映射——哪怕只改了一行 src/ 目录名，没同步更新 "psr-4" 配置，composer dump-autoload 就不会注册任何类。
