软链 vendor 目录无法真正共享，因 autoload.php 硬编码项目路径，导致 psr-4 映射错乱、类加载失败及插件逻辑错位；微服务中仅缓存与构建产物可共享，运行期 vendor 必须隔离。
不能共享全局 vendor 目录，软链只是把问题从“多个目录”搬到“一个目录”，IO 风暴和类加载错乱照旧发生。
为什么软链 vendor 到共享路径会失败
软链本身不解决根本矛盾：每个项目生成的 vendor/autoload.php 是硬编码当前项目路径的，一旦被多个服务共用，PSR-4 映射、classmap 路径、甚至 __DIR__ 计算全指向链源——比如所有服务都映射到 /shared/vendor/autoload.php，但该文件内部写的却是 require __DIR__ . '/composer/autoload_real.php'，而 __DIR__ 永远是 /shared/vendor，不是各自项目根目录。
- 现象：服务 A 正常，服务 B 启动报
Class not found: App\Http\Controllers\XxxController，尽管类文件明明在自己src/下 - 原因：A 的 autoload.php 被 B 加载，但它的 PSR-4 规则只注册了 A 的
App\→/srv/a/src，对 B 完全无效 - 更隐蔽的问题：Composer 插件（如 laravel-shift）或脚本钩子依赖
getcwd()或realpath(__DIR__.'/../')，软链下返回的是共享路径而非项目路径，直接触发逻辑错位
真正在微服务群中能落地的“共享”只有缓存和构建产物
所谓“共享”，必须分层对待：开发期可复用缓存，构建期可复用二进制产物，运行期必须隔离 vendor。
- 缓存共享：确保所有节点用同一
COMPOSER_HOME（如/var/cache/composer），并挂载到 SSD 或 tmpfs；禁止落在 NFS 上 - 构建产物共享：CI 中统一
docker build，RUN composer install --no-dev --prefer-dist --optimize-autoloader --classmap-authoritative，把vendor/打进镜像层，而不是部署时再装 - 若需快速联调（如 user-service 依赖未发版的 user-sdk），用
"type": "path"仓库 + 软链 SDK 目录，但仅限开发机；上线前必须切回 VCS 仓库并提交composer.lock
如果硬要上软链，唯一勉强可行的场景与限制
仅适用于单机多容器、且所有服务完全同构（PHP 版本、扩展、启动方式、命名空间结构全一致）的调试环境，且必须满足：
- 所有服务的
composer.json中autoload配置完全相同，且所有源码路径相对于共享vendor的位置一致（例如全部源码都在/app/src） - 禁用所有依赖工作目录的插件，删掉
scripts段中所有含exec()、shell_exec()、getcwd()的自定义逻辑 - 安装时强制指定
--classmap-authoritative，并验证vendor/composer/autoload_classmap.php确实覆盖全部类——否则 fallback scandir 会在运行时扫错目录 - 部署后立刻
chmod -R a-w /shared/vendor，防止某服务意外写入导致污染
真正卡住集群的，从来不是磁盘空间或带宽，而是 autoload 机制在非本地存储上的路径解析延迟和元数据锁竞争。软链 vendor 不是捷径，是把 IO 风暴和类加载不确定性打包塞进同一个坑里。
