Composer虚拟包是通过composer.json中provide字段声明的占位符，不安装代码也不生成autoload，仅在依赖解析阶段声明“已提供某能力”以阻止重复安装或版本冲突。
虚拟包本身不参与安装，但它是团队协同中控制依赖边界、规避冲突的隐形锚点；统一配置的关键不在“装什么”，而在“不让装什么”。
什么是Composer虚拟包？
虚拟包（virtual package）不是真实存在的库，而是通过 provide 字段在 composer.json 中声明的“占位符”。它告诉 Composer：“我这个项目已经提供了某项能力，其他包别再重复装了”。比如 Laravel 项目常声明："provide": {"psr/log": "1.0.0"}，表示自己已实现 PSR-3 日志接口，无需再引入 psr/log 包。
它不下载代码、不生成 autoload、不写入 vendor/，只参与依赖解析阶段的版本兼容性判断。
为什么团队要用虚拟包协同？
常见场景是多个子项目共用一套底层能力（如统一日志、缓存、认证），但又不想把它们打包成独立可发布包。此时虚拟包能避免以下问题：
- 不同成员本地执行
composer require psr/log，导致实际装的版本不一致（^1.0vs^2.0） - CI 环境因未显式约束而自动升级到不兼容的
monolog/monologv3，引发LoggerInterface方法签名变更报错 - 某人误删
composer.lock后重装，整个依赖树重新解析，引入意外的间接依赖
虚拟包在这里的作用是“堵住缺口”——只要主项目声明了 "provide": {"psr/log": "1.0.0"}，任何要求 "psr/log": "^2.0" 的包就会被直接拒绝，报错而非静默降级。
如何配置才能真正统一团队行为？
光加 provide 不够，必须配合三处硬性约束：
- 在
composer.json中强制设置"minimum-stability": "stable"和"prefer-stable": true，防止开发时手滑引入dev-main分支 - 所有成员必须提交并共享
composer.lock，且 CI 流程只跑composer install --no-interaction，禁用update - 在团队
.gitignore里加一行/vendor/，同时明确禁止提交任何vendor/下的文件——虚拟包不改变这一铁律
额外提醒：如果项目用了私有仓库或路径仓库（"type": "path"），虚拟包的 provide 仍有效，但需确保所有协作者的本地路径结构一致，否则 Composer 解析时会跳过该仓库，导致提供关系失效。
容易被忽略的兼容性陷阱
虚拟包的 provide 声明不会自动向下兼容。例如你写了 "provide": {"psr/log": "2.0.0"}，但某个包只认 "psr/log": "^1.0"，Composer 仍会报冲突，而不是自动桥接。
更隐蔽的是 PHP 版本平台约束：若虚拟包声明的版本号对应一个仅支持 PHP 8.1+ 的接口契约，而团队有人还在用 PHP 7.4 开发，composer install 会直接失败，且错误信息里根本不会提“虚拟包”，只显示“your-vendor/core requires php ^8.1”，让人误以为是主项目限制。
所以，虚拟包不是免检通行证，它把隐性依赖显性化了——问题没消失，只是从运行时报错提前到了安装阶段。这点必须让每个成员心里有数。
