多个项目不能共用一个 composer.json，否则会导致依赖冲突、自动加载错乱、vendor 目录污染及 composer install 静默覆盖版本；必须每个项目独立维护 composer.json、vendor/ 和 composer.lock。
多个项目共用一个 composer.json 会出什么问题
不能共用。Composer 的设计前提就是「每个项目一个 composer.json」，强行共享会导致依赖冲突、自动加载错乱、vendor/ 目录污染，甚至 composer install 时静默覆盖其他项目的包版本。
常见错误现象：Class not found 却查不到类在哪；composer update 后某个项目突然报 Method does not exist；vendor/autoload.php 加载了本不该存在的类。
- 每个项目必须有独立的
composer.json和vendor/ - 不要把多个项目的
composer.json放到同一级目录下再统一执行composer install - 如果想复用配置（如私有源、脚本模板），用
composer create-project+ 自定义 skeleton，而不是共享文件
composer global 不是多项目共享依赖的解法
composer global 装的是全局命令行工具（比如 laravel/installer 或 phpunit/phpunit），不是给你的 Web 项目自动加载用的。它不会出现在任何项目的 vendor/autoload.php 中，也不会被 require 到代码里。
典型误用场景：把 monolog/monolog global require 了，然后在 A 项目里 use Monolog\Logger; —— 结果直接报错。
-
composer global的vendor/在~/.composer/vendor/，和项目无关 - 全局 autoloader 不参与项目级自动加载逻辑
- 真正需要复用的库（如自建的工具包），应发布为私有包，用
repositories+require引入各项目
如何安全地在多个项目中复用同一套私有包
核心思路：不共享 vendor/，而是让每个项目独立 require 同一个包源，靠 Composer 的依赖解析机制保证一致性。
使用场景：公司内部通用 SDK、基础服务客户端、统一日志封装等。
- 把私有包推送到 Git 仓库（如
git@xxx.com:org/sdk.git），确保有composer.json和语义化版本 tag - 在每个项目的
composer.json中添加repositories段，指向该 Git 地址 - 运行
composer require "org/sdk:^1.2"，各项目各自安装、各自 autoload - 更新时仍需进每个项目执行
composer update org/sdk，无法一键批量更新
注意：path 类型仓库（如 "type": "path", "url": "../my-sdk"）适合本地开发联调，但上线前必须切回 Git 类型，否则部署失败。
多项目环境下 composer.lock 必须提交，且不能忽略
不提交 composer.lock 是多项目协作中最容易被轻视的坑。它不是“可选缓存”，而是锁定每个项目确切依赖树的唯一依据。
常见后果：CI 构建成功，本地 composer install 却失败；A 项目升级了 symfony/console，B 项目没动却因 autoload 冲突启动不了。
-
composer.lock是项目级快照，跨项目不可复用，也不可删除 - 所有项目都应把
composer.lock提交到 Git，且禁止在 CI 中用composer install --no-lock - 如果多个项目依赖同一私有包，该包自身的
composer.lock不影响下游项目 —— 下游只认自己锁里的哈希和版本
真正麻烦的是当私有包本身有未锁死的子依赖（比如用了 "dev-master"），这时候每个项目锁住的其实是不同 commit，表面看没问题，实则埋雷。
