require 'vendor/autoload.php' 是硬性前提，漏掉则自动加载失效；vendor-dir仅支持项目内相对路径，跨目录会导致autoload.php路径错乱；多项目共享应使用符号链接而非移动vendor。
require 'vendor/autoload.php' 是硬性前提，外部路径不改变这一点
哪怕你把 vendor 移到项目外、用符号链接、甚至改了 vendor-dir，只要没在脚本开头 require 自动加载入口，就一定会报 Class not found。这个文件不是“可选辅助”，而是整个 autoload 机制的启动开关——它注册 spl_autoload_register()、载入映射表、预加载 files 列表。漏掉这行，Composer 下载再全也没用。
vendor-dir 只能指向项目内子目录，不能跨出项目根目录
composer.json 里的 "config": {"vendor-dir": "../libs"} 看似能跨目录，但实际只允许相对路径且必须落在项目可写范围内。设成 /opt/my-vendor 或 C:\shared\vendor 会导致：composer dump-autoload 失败、autoload.php 生成的路径错乱、第三方包的 PSR-4 映射失效（因为它们的 autoload 配置默认基于 vendor 目录做相对解析）。
常见错误现象：
- 类能 new 出来，但调用方法时报
Call to undefined method—— 实际是加载了旧版或空壳文件 -
phpunit找不到命令，或执行时提示Class "PHPUnit\Framework\TestCase" not found - IDE（如 PHPStorm）无法跳转到 vendor 内部类，索引始终灰色
想复用外部代码？别动 vendor，用 path repository 更安全
如果你的真实需求是让多个项目共用同一份本地开发中的工具包（比如 my-utils），正确做法不是挪 vendor，而是配置 repositories：
在主项目 composer.json 中加：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
"repositories": [
{
"type": "path",
"url": "../my-utils"
}
]
然后运行 composer require my-vendor/my-utils:dev-main。Composer 会自动创建符号链接（Linux/macOS）或复制（Windows），且源码修改实时生效。上线前切回 packagist 或私有仓库，业务代码完全不用改。
注意点：
-
../my-utils必须包含合法的composer.json，且"name"和"version"要匹配require的值 - Windows 默认复制而非链接，如需实时同步，得手动启用开发者模式或改用 WSL
- 不要在
path仓库里放require其他path包——循环依赖会直接让composer install卡死
符号链接是唯一“看起来像外部”的可行方案
如果非得让物理 vendor 存在项目外（例如多项目共享缓存、Docker volume 挂载），唯一稳定方式是保持 vendor 名字和位置不变，但用符号链接指向外部路径：
- Linux/macOS：
ln -s /shared/vendor ./vendor - Windows（管理员）：
mklink /D vendor C:\shared\vendor
这样 Composer 完全无感，所有命令照常运行，autoload.php 路径也绝对正确。但要注意：多个项目共用同一 vendor 目录时，必须确保它们的 composer.lock 依赖版本完全兼容，否则一个项目 composer update 可能悄悄破坏另一个项目的运行环境。
真正容易被忽略的是：符号链接本身没有权限继承。如果 /shared/vendor 所在分区是 NTFS 或 ext4 且挂载时禁用了执行位，PHP 可能因无法读取 autoload.php 报 failed to open stream，而不是更明确的类未找到错误。
