不能。每个PHP项目必须有独立的vendor目录和composer.json，因Composer依赖隔离基于项目根目录，共用会导致Class not found、autoload.php路径失效、版本冲突等错误。
多个PHP项目能共用一个vendor目录吗
不能。每个项目必须有自己独立的 vendor/ 目录和 composer.json，这是 Composer 依赖隔离的底层前提。
常见错误现象：Class not found、require_once(): Failed opening required 'vendor/autoload.php'、composer install 报版本冲突或 stability 不匹配——根本原因就是 vendor 被复用或软链共享。
- Composer 的 autoloader 是按项目根目录生成的，
vendor/autoload.php里硬编码了当前项目的 PSR-4 映射和路径快照，换项目不删它，就会加载旧映射 - IDE 和 PHP CLI 都依赖该文件定位类，缓存（opcache / IDE index）不会自动刷新上下文
- 即使你用
--working-dir切换路径，autoload_static.php 仍是上一次生成的，极易出错
composer install 和 composer update 哪个该用于部署
上线、CI/CD、换机器拉代码时，必须用 composer install。
composer update 是重算依赖树，会忽略 composer.lock，导致本地装的包版本和线上不一致——函数不存在、行为突变、安全补丁漏掉，全由此起。
- 团队协作中，
composer.lock必须提交 Git，它是多环境一致性的唯一依据 - 没有
composer.lock？说明流程不规范，install会退化成update，风险极高 - 只升级某个包：用
composer update vendor/package-name，避免全量更新引入意外变更
如何安全地在生产环境跳过开发依赖
别只靠 --no-dev，要配合 COMPOSER_DEV_MODE 和 config.platform 三层控制。
单纯加 --no-dev 只是不装 require-dev 里的包，但 autoload-dev 的路径仍会被注册——如果某 dev 包提供了运行时需要的工具（比如 symfony/var-dumper），关掉就真用不了。
- 生产部署推荐写法：
COMPOSER_DEV_MODE=0 composer install --no-dev，双保险 -
config.platform用来“骗过” Composer 的平台检查：比如线上是 PHP 8.1 且没装ext-xdebug，就在composer.json里写"php": "8.1.0"和"ext-xdebug": false（注意值必须是具体字符串或false，不能用^） - 真实缺失扩展？
config.platform挡不住运行时报错，该装的扩展还得装；它只解决依赖解析阶段的阻断
Docker 中怎么避免 Composer 环境污染
在 Docker 构建阶段，最容易踩的坑是把宿主机的 vendor/ 或全局 cache 直接 COPY 进镜像，或者复用 ~/.composer/cache 路径造成权限/版本错乱。
正确做法是让每层构建干净独立：基础镜像不带任何 vendor，每次 composer install 都在容器内重新执行，靠 Composer 自身 cache 复用 dist 包（默认开启）。
- Dockerfile 中不要
COPY vendor/ ./vendor/—— 这破坏可重现性，也绕过 lock 文件校验 - 用多阶段构建：build 阶段装依赖并
dump-autoload --classmap-authoritative，runtime 阶段只 COPYvendor/和autoload.php - 确保构建时 PHP 版本与线上一致；若用不同小版本（如 8.2 → 8.1），需清掉 build 阶段的
~/.composer/cache或设COMPOSER_CACHE_DIR=/tmp/composer-cache避免跨版本污染
真正容易被忽略的是：autoload 的静态映射一旦生成就不会自动更新，哪怕你改了 composer.json 里的 PSR-4 配置，也得手动 composer dump-autoload；而这个动作，在 CI 或 Docker 构建中常被遗漏，结果类还在旧路径下找。
