Composer why命令排查由于 PSR-16 冲突导致的缓存组件失效-composer-PHP中文网

composer why 查不出 psr-16 冲突，因其仅追踪已安装包依赖链，无法识别接口实现冲突或运行时加载顺序问题；psr-16 失效主因是多个实现共存且未显式绑定、autoload 路径错位或 di 未配置。

composer why命令排查由于 psr-16 冲突导致的缓存组件失效

composer why 不会查出 PSR-16 冲突

PSR-16 是接口标准，不是具体包；composer why 只能追踪已安装包的依赖链，对“谁实现了 PsrSimpleCacheCacheInterface”或“谁覆盖了另一个实现”完全无感。它查不到接口实现冲突，也看不到运行时加载顺序——而 PSR-16 失效往往就卡在这两点上。

实际失效场景：多个缓存实现共存且未显式绑定

典型表现是调用 $cache->get() 时抛出 Fatal error: Interface 'PsrSimpleCacheCacheInterface' not found 或 Class not found，但 composer show psr/simple-cache 显示已装、vendor/autoload.php 也正常加载。根本原因不是缺包，而是：
– 两个包（如 symfony/cache 和 laravel/framework）都声明了 "psr/simple-cache": "^1.0"，但各自带了自己的实现类
– 你没在 DI 容器里明确绑定 PsrSimpleCacheCacheInterface 到某个具体类，框架随机选了一个（或根本没选）
– 某个实现类因 autoload 路径错位、命名空间不匹配，被 Composer 跳过注册

运行 composer show --platform，确认 psr/simple-cache 版本是 ^1.0 或 ^2.0（注意 v1 和 v2 的接口方法有差异）
检查 vendor/composer/autoload_psr4.php，搜索 "Psr\SimpleCache\" —— 正常应映射到 vendor/psr/simple-cache/src/；若为空，说明 psr/simple-cache 包本身 autoload 没生效
执行 composer dump-autoload -v | grep "Psr\\SimpleCache"，看是否扫描到了 vendor/psr/simple-cache/src/ 下的文件；若没出现，可能是该目录被 .gitignore 或 composer.json 的 autoload.exclude-from-classmap 排除

验证哪个实现类真正在用

别猜，直接看运行时加载结果：
在出问题的代码前加一行：
var_dump(class_exists('SymfonyComponentCacheAdapterPhpArrayAdapter'));
var_dump(class_exists('IlluminateCacheArrayStore'));
再加：
var_dump(interface_exists('PsrSimpleCacheCacheInterface'));

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

如果 interface_exists 返回 false，说明 psr/simple-cache 的 autoload 根本没触发，优先查 vendor/composer/autoload_static.php 里是否有 Psr\SimpleCache\ 映射项
如果接口存在、但某个实现类返回 false，说明那个包的 autoload 配置失效（比如 symfony/cache 的 psr-4 前缀写成了 "Symfony\Component\Cache\": "src/" 却把源码放在 lib/）
如果多个实现类都存在，但 new $cache 报错，说明你没手动 new 实现类，而是靠 DI 自动注入——此时必须查框架配置（如 Laravel 的 config/cache.php 中 'default' 对应的驱动是否启用、是否 require 了对应服务提供者）

PSR-16 实现冲突的修复动作

这不是版本锁问题，而是“谁说了算”的问题。修复核心是收口：让项目只有一个权威实现，并确保它被 autoload 和 DI 同时认可。

删掉冗余实现：如果用了 Laravel，就不要额外 composer require symfony/cache；反之亦然。保留一个，composer remove 另一个
强制 autoload 生效：在 composer.json 的 autoload.psr-4 里补一条 "Psr\SimpleCache\": "vendor/psr/simple-cache/src/"（仅临时调试用，正式环境应靠包自身 autoload）
DI 绑定不能省：Laravel 需确保 IlluminateCacheCacheServiceProvider 已注册；Symfony 项目需在 config/services.yaml 里显式 bind: PsrSimpleCacheCacheInterface: '@cache.app'
别信 optimize-autoloader：开启后 classmap 会固化路径，一旦实现类移动或重命名，旧映射残留导致加载失败。开发期保持关闭，上线前再开