Composer虚拟包是通过provide字段声明的逻辑占位，不安装真实代码而告知Composer某抽象契约已被满足；日志接口用它可避免强制依赖具体实现，只需在composer.json根级声明"psr/log": "*"并真正实现LoggerInterface。
什么是 Composer 虚拟包，为什么日志接口要用它
Composer 本身不提供“虚拟包”原语，所谓“虚拟包”是通过 replace 或 provide 字段在 composer.json 中声明的逻辑占位——它不安装真实代码，只告诉 Composer：“这个抽象契约已被满足”。日志接口（如 PsrLogLoggerInterface）属于典型的 PSR 标准契约，多个库依赖它，但你不希望强制用户装某一个具体实现（比如 monolog/monolog），这时用 provide 声明自己“提供了该接口实现”，是最轻量、最合规的做法。
关键点：不是写个空类就完事，而是让 Composer 认出你的包能替代标准接口依赖。
如何在 composer.json 中正确声明日志接口提供关系
provide 字段必须写在根级，值为关联数组，键是包名（含命名空间规范），值是版本约束（哪怕只是 *）。对 PSR-3 日志接口，标准包名是 psr/log：
{
"name": "your-vendor/your-package",
"type": "library",
"provide": {
"psr/log": "*"
},
"autoload": {
"psr-4": {
"YourVendor\YourPackage\": "src/"
}
}
}
注意几个硬性要求：
-
psr/log必须全小写，大小写敏感，写成PSR/log或psr/Log都不会被识别 - 版本号不能留空，
"psr/log": ""无效；"*"是最常用且安全的选择 - 如果你同时实现了其他 PSR（如
psr/container），每项需单独列在provide下，不能合并 - 不要加
requirepsr/log——那会引入实际依赖，违背“仅声明提供”的初衷
声明之后，你的类该怎么实现 LoggerInterface
声明 provide 只是告诉 Composer “我能用”，不代表自动满足类型约束。你仍需在代码中真正实现 PsrLogLoggerInterface，否则运行时会报 Class ... does not implement interface PsrLogLoggerInterface。
常见错误场景：
- 类用了
implements PsrLogLoggerInterface，但没实现全部 8 个方法（emergency()、alert()…log()），PHP 会直接拒绝加载 - 自动加载路径没覆盖到接口文件（比如漏了
psr/log的 autoload），导致class not found——此时应确认是否已安装psr/log包（它只含接口定义，无实现，体积极小） - 用了 PHP 8.0+ 的联合类型或返回类型，但目标项目 PHP 版本更低，导致解析失败
最小可行实现示例（仅示意结构，非完整）：
<?php namespace YourVendorYourPackage;
<p>use PsrLogLoggerInterface;
use PsrLogLogLevel;<p>class NullLogger implements LoggerInterface
{
public function emergency($message, array $context = []): void { }
public function alert($message, array $context = []): void { }
// ... 其余方法同理，至少声明签名
public function log($level, $message, array $context = []): void { }
}</p>
为什么不用 replace 或 require-dev 来处理日志依赖
replace 用于完全替代另一个包（如 fork 后替换原包），而 psr/log 是接口规范，没有“被替换”的实体包；强行 replace 会导致 Composer 认为 psr/log 已被删除，其他依赖它的包可能无法解析。
至于 require-dev，它只影响开发环境，无法解决生产环境中其他包对你“是否提供日志能力”的依赖判断 —— Composer 安装时只看 require 和 provide。
真正容易被忽略的一点：如果你的包被别人作为依赖引入，而他们又显式 require 了 monolog/monolog，Composer 不会报错，但最终生效的是 Monolog 的实现，不是你的。换句话说：provide 解决的是“可安装性”，不是“运行时优先级”。要确保你的实现被使用，还得靠 DI 容器绑定或手动实例化，这点和 Composer 声明无关。
