vendor目录不能直接复用，因其是composer依赖安装产物，无统一入口、版本声明且易引发autoload冲突；应将逻辑抽为独立composer包并发布。
vendor 目录本身不能直接当模块复用
Composer 的 vendor 是依赖安装的**产物目录**，不是设计用来被其他项目直接引用的模块。它没有统一入口、无版本声明、路径硬编码风险高，强行 symlink 或 require 会导致 autoload 冲突、类名冲突、更新失败等问题。
真正可行的路径是：把你要复用的逻辑抽成独立包，发布为 Composer 包，再通过 composer require 引入。
如何快速把已有代码变成可复用的 Composer 包
假设你有一组工具类在 my-utils 目录下，想让多个项目都能 composer require my-company/my-utils：
- 在
my-utils根目录放composer.json，至少包含："name"（格式vendor/name）、"autoload"（推荐"psr-4"）、"type": "library" -
"autoload"示例：{"psr-4": {"MyCompany\Utils\": "src/"}}，然后把类文件放到src/下，命名空间匹配 - 推送到 Git 仓库（GitHub/GitLab），确保有稳定 tag（如
v1.0.0）或支持dev-main分支 - 主项目中运行
composer require my-company/my-utils:^1.0，Composer 会自动下载并注册 autoloader
为什么不能直接 symlink vendor 到其他项目
常见错误现象：Class not found、Cannot declare class XXX, because the name is already in use、vendor/autoload.php 被多次 require 导致 fatal error。
根本原因：
-
vendor/autoload.php是为当前项目生成的，依赖当前composer.json的 autoload 配置和包顺序 - 不同项目可能 require 同一包的不同版本，symlink 会破坏 Composer 的版本隔离机制
- Composer 脚本（如
post-install-cmd）不会触发，资源文件（如config/、migrations/）无法自动发布 - CI/CD 构建时，
vendor不是源码，无法被 git track，symlink 更易断裂
如果只是临时共享、还没法发包，有什么折中方案
仅限开发阶段、小团队、短期协作，不建议上生产：
- 用 Composer 的
pathrepository：在主项目的composer.json中加{"repositories": [{"type": "path", "url": "../my-utils"}]}，再composer require my-company/my-utils:dev-main - 确保
my-utils/composer.json里有"autoload"且已执行过composer dump-autoload - 注意：
path模式下，composer update会直接写入源目录，相当于“软链接+自动加载注册”，但仍需避免多项目同时改同一份源码 - 绝对不要手动修改主项目的
vendor/composer/autoload_psr4.php—— 下次dump-autoload就会被覆盖
真正稳定的复用，永远来自明确的包边界、版本约束和 autoload 隔离。vendor 目录是结果，不是接口。
