PSR接口仅定义契约，需配合具体实现库使用；选型应兼顾场景、兼容性与维护性，避免仅引入PSR包而忽略真实实现及DI注入。
PSR接口本身不能直接用，必须配一个具体实现
PSR标准（比如psr/http-client、psr/log、psr/cache）只是定义了一组接口和行为契约，不带任何功能代码。你composer require psr/http-client之后，new不出任何实例——它连类都没有，只有interface。
所以真正干活的，是实现了这些接口的库。选哪个，取决于你的场景、依赖现状和维护意愿：
-
GuzzleHttpClient：生态最广，文档最全，插件丰富；但体积大，若只发几个简单请求，有点“杀鸡用牛刀” -
SymfonyHttpClientHttpClient：轻量、异步友好、内存占用低，适合现代PHP项目；但对PHP 7.2以下支持弱，且部分高级功能（如重试策略）需手动组合 -
monolog/monolog（对应psr/log）：事实标准，稳定可靠；但默认StreamHandler在高并发下可能成为I/O瓶颈 -
cache/apcu-adapter（对应psr/cache）：APCu本地缓存快，但仅限单机；若用Redis，得换cache/redis-adapter，别直接装psr/cache就以为能连Redis
别在composer.json里写“psr/*”当实际依赖
常见错误：看到项目要求“支持PSR-16”，就在composer.json的require里加一行"psr/cache": "^3.0"，然后以为缓存功能就有了。结果运行时报Class "Psr\Cache\CacheItemPoolInterface" not found——不对，这个接口一定存在；真正报错的是Class "MyAppCacheRedisPool" not found或Uncaught TypeError: Argument 1 passed to MyAppService::__construct() must be an instance of PsrCacheCacheItemPoolInterface，因为你没传入一个真实对象。
正确做法是：
- 把
psr/*包放进require——只为了类型提示和静态分析（IDE、PHPStan）能认出接口 - 另选一个具体实现包，也放进
require，比如"cache/redis-adapter": "^1.2" - DI容器或构造函数中，明确注入该实现类的实例，而不是试图
new接口
多个实现共存时，注意自动加载冲突和版本兼容
比如你同时用了guzzlehttp/guzzle（自带psr/http-client实现）和symfony/http-client（也实现同一接口），表面上没问题，但可能出现两种情况：
- Composer因版本约束失败：
guzzlehttp/guzzle ^7.5要求psr/http-client ^1.0，而某个旧版symfony/http-client只认^2.0，就会触发your requirements could not be resolved - 运行时行为不一致：两个库都注册了
PsrHttpClientClientInterface的实现，但你的DI容器（如Laravel的Container）只绑定了其中一个；如果某处代码悄悄用了另一个，就可能绕过你配置的中间件、超时或日志逻辑 - 更隐蔽的问题：某些实现会偷偷改全局状态（比如
GuzzleHttpHandlerStack的默认栈），另一个库初始化时可能被意外污染
建议：一个项目里，同一PSR接口只保留一个主力实现；临时需要多客户端时，显式传参，不依赖容器自动解析。
PSR-0遗留库混用时，实现选择要格外小心
如果你的老项目还拖着一个PSR-0类库（比如swiftmailer/swiftmailer:^5.4），而你又想引入psr/log实现，别直接装monolog/monolog:^2.0——它要求PHP >=7.2，而Swiftmailer v5.x的PSR-0结构常跑在PHP 5.6上。这时你会卡在“新日志库用不了，老日志适配器又没人维护”的死结里。
解法很务实：
- 优先找兼容旧环境的实现：比如
php-fig/log+knplabs/github-api附带的简易NullLogger，或者自己写个三行class LegacyLogger implements PsrLogLoggerInterface - 避免升级PSR包主版本：用
"psr/log": "1.1.4"而非^2.0，因为v1完全兼容PHP 5.3+ - 别指望Composer自动加载PSR-0类——
composer.json里的psr-0字段在Composer 2.0+已彻底失效，必须用spl_autoload_register()手动补规则，或改用classmap（更适合少量类）
真正的难点从来不是“哪个实现更快”，而是“哪个实现不会让现有代码突然崩掉”。接口是干净的，现实是打补丁拼起来的。
