利用Composer进行多应用开发？共享依赖与独立隔离的平衡-composer-PHP中文网

不能共享vendor目录或共用composer.json，因composer依赖隔离基于项目根目录；多项目须各自独立vendor和composer.json，否则必现class not found、autoload.php路径失效、版本冲突等确定性错误。

利用composer进行多应用开发？共享依赖与独立隔离的平衡

不能共享 vendor/ 目录，也不能共用 composer.json —— 这不是配置技巧问题，而是 Composer 的设计边界。所谓“平衡”，其实是明确哪些该共享、哪些必须隔离，并把共享逻辑落到可验证的机制上。

为什么 path 仓库是唯一安全的“共享”方式

本地开发时想让多个项目用同一套 SDK 或基础组件，path 类型仓库是唯一被 Composer 官方支持且不破坏隔离性的方案。

子包（如 acme/sdk）必须有独立 composer.json，name 字段全限定，autoload 配置 PSR-4 路径与命名空间严格匹配
主项目中通过 repositories 声明：
```
{"type": "path", "url": "../acme-sdk"}
```
，再 require 它
默认安装为符号链接，改源码实时生效；加 "options": {"symlink": false} 可切为复制模式，适合 CI 构建
生产环境禁止用 path：它只应出现在开发阶段的 composer.json 中，上线前必须替换为 Git 或私有 Packagist 地址

多租户或子应用必须生成独立 composer.json

当不同租户、工具或微服务模块需要不同版本的同一包（比如一个要 guzzlehttp/guzzle:^6.5，另一个要 ^7.5），你无法靠配置绕过 Composer 的单解限制。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

每个租户目录（如 tenants/a/）下放独立 composer.json，动态生成时只允许 name、require、autoload 字段可变
require 中的包名必须校验白名单，版本约束必须符合语义化（拒绝 1.*.* 或 dev-main）
安装命令必须带 -d 指定目录，且禁用脚本：composer install --no-scripts --no-interaction -d tenants/a
运行时不能 require vendor/autoload.php，而要显式 include_once 'tenants/a/vendor/autoload.php'，并注意 ClassLoader 注册顺序（先租户后主项目）

共享 vendor / 共用 composer.json 的典型错误现象

这些不是“偶尔出错”，而是每次都会触发的确定性失败，只是表现形式不同。

require_once(): Failed opening required 'vendor/autoload.php'：因为 autoload.php 是静态快照，路径和映射都绑定当前 composer.json 上下文
Class not found：软链共享 vendor/ 后，opcache 缓存复用 + autoload 映射冲突，导致类加载路径错乱
Root composer.json requires X ^1.0 and X ^2.0：Composer 解析器对每个包名只接受一个解，强行写两个版本约束会直接报错
Package has a dependency on Y which does not match your minimum-stability：不同项目 composer.json 中 stability 设置不一致，统一执行 install 时按第一个读到的为准

CI/CD 和 Docker 中最容易忽略的三个点

自动化流程里，人眼看不到的环节最危险。

composer.lock 文件是否由带 --no-dev 的 install 生成？如果它本身记录了 dev 包，--no-dev 参数在部署时只会跳过安装，但 autoload_dev.php 仍可能被注册
Docker 构建中是否显式写了 RUN composer install --no-dev --optimize-autoloader --no-scripts？别依赖 ENV COMPOSER_NO_DEV=1，它会影响所有后续命令
Git subtree 子项目是否执行了 composer install --no-autoloader --no-scripts？否则它的 autoload 会被主项目自动加载器捕获，造成命名空间污染

真正难的不是写对命令，而是让每个项目守住自己的根目录边界——composer.json 在哪，vendor/ 就在哪，autoload.php 就为谁服务。越想省事去“共享”，越容易在运行时收到一连串 Class not found。