Composer 不支持虚拟包，需通过 replace 声明替代、PSR 接口定义契约、DI 容器按配置加载具体驱动（如 OSS/S3 Adapter）来实现配置抽象层。
Composer 本身不提供“虚拟包”概念，所谓虚拟包（virtual package）是某些包管理器（如 Debian APT）中用于声明能力而非真实代码的抽象占位符；composer 没有原生支持该机制。但你在项目中想实现「配置抽象层」——比如让业务代码不依赖具体 SDK（如 alibabacloud/oss-sdk 或 aws/aws-sdk-php），而是通过统一接口切换底层实现——这完全可行，只是不能靠“虚拟包”达成，得靠 Composer 的 replace + 抽象接口 + PSR 标准协同完成。
为什么不能用虚拟包？
Composer 的 replace 字段虽可声明“本包替代某包”，但它只影响依赖解析，不生成任何运行时抽象。例如你写：
"replace": {
"aws/aws-sdk-php": "*",
"alibabacloud/oss-sdk": "*"
}
这只是告诉 Composer：“别再装这两个包了，我来顶替”。但顶替什么？没接口、没契约、没类型约束，PHP 运行时照样报 Class not found。它不解决“如何让 $client->putObject() 在 OSS 和 S3 下都可用”这类问题。
真正起作用的是 PSR 接口 + replace + 实际驱动
要达成配置抽象层，必须满足三个条件：
- 定义或采用一个稳定接口（如
League\Flysystem\FilesystemInterface） - 用
replace声明你的包“提供”该接口的能力（仅语义层面） - 在运行时通过 DI 容器或工厂，根据配置加载对应驱动（
League\Flysystem\AwsS3V3\AwsS3V3Adapter或League\Flysystem\Oss\OssAdapter）
典型实践（如 hyperf/filesystem）：
- 它在
composer.json中replace了league/flysystem的部分能力，但核心仍是依赖league/flysystem抽象层 - 它不自己实现
write()/read()，而是把调用转发给注入的 Adapter - Adapter 由配置决定：填
oss就 newOssAdapter，填s3就 newAwsS3V3Adapter
容易踩的坑：replace 写错导致循环依赖或加载失败
常见错误包括：
-
replace列了psr/log却没实际提供Psr\Log\LoggerInterface实现 → 运行时报Class not found - 在包 A 中
replace包 B，又在require里写了包 B → Composer 解析失败，提示 “conflict” - 以为
replace能自动绑定接口实现，结果 DI 容器里没注册对应服务 →make(FilesystemInterface::class)报EntryNotFoundException
正确做法是：replace 仅用于语义声明（如发布一个“兼容 Flysystem 的阿里云适配器包”），真正的解耦靠接口类型提示 + 配置驱动加载，不是靠 Composer 替换文件。
最易被忽略的一点：Composer 的 replace 不改变自动加载逻辑，也不生成任何代理类。它只是一张“说明书”，告诉依赖解析器“这个能力我包了”——至于你包没包住，得看代码里有没有真家伙。
