psr/cache 必须用 psr/cache:^3.0 而非 psr/cache:3.0 或 psr/cache，因其是无真实 tag 的元包，依赖 Composer 内部映射；^ 符号触发版本约束匹配，否则无法识别有效版本。
psr/cache 不能直接装 psr/cache:3.0
你执行 composer require psr/cache:3.0 会报 Could not find package psr/cache，不是网络问题，也不是镜像源失效——psr/cache 是一个“虚拟包”，它没有真实 tag，也没有 v3.0 这样的发布版本。Packagist 上的 psr/cache 是由 PSR 组织托管的元包（meta-package），Composer 通过内部映射规则识别它，但必须显式带版本约束符，且写法严格：psr/cache:^3.0 或 psr/cache:^2.0，不能省略 ^，也不能写成 3.0.0 或 v3.0。
为什么必须加 ^3.0 而不是直接 psr/cache
PSR 元包不设默认分支或默认版本，Composer 不会自动猜用哪个主版本。不写约束时，它尝试解析为“最新稳定版”，但 psr/cache 没有 stable 标签，所以直接 require psr/cache 就失败。加 ^3.0 的作用是告诉 Composer：“我要 PSR-6 v3 规范的接口定义”，它才会去匹配 Packagist 映射的对应版本逻辑（实际拉取的是 psr/cache 的 3.x 分支快照）。
-
psr/cache:^3.0→ 对应 PHP 8.0+ 环境，含CacheItemPoolInterface::getItems()等新签名 -
psr/cache:^2.0→ 兼容 PHP 7.0+，接口更轻量，无批量操作方法 - PHP 版本不匹配会导致后续实现类（如
symfony/cache）无法正常工作，不是报错在require阶段，而是在运行时Class not found或方法不存在
装完发现 vendor/psr/cache/src/ 为空或没 CacheInterface.php
这说明安装看似成功，但文件没真正写入。常见原因有三个：
- 用了过旧的 Composer（
composer --version ），对 PSR 元包支持不完整，升级命令：composer self-update - 全局源被污染，比如配置了失效的私有镜像，重置为官方源：
composer config -g repo.packagist composer https://packagist.org - 装完后没触发 autoload 注册，手动跑一次：
composer dump-autoload -o，再检查vendor/composer/autoload_psr4.php中是否有'PsrCache\' => array($vendorDir . '/psr/cache/src')
装了 psr/cache 却提示 Class 'PsrCacheCacheInterface' 找不到
这不是包没装好，而是自动加载没生效或被覆盖。PSR 接口包只提供定义，不带实现，也不执行任何代码，所以不会触发 files 或 classmap 加载逻辑。关键检查点：
- 确认
vendor/psr/cache/src/CacheInterface.php文件真实存在，且内容以namespace PsrCache;开头 - 不要在代码里
require_once 'vendor/psr/cache/src/CacheInterface.php'—— 这绕过了命名空间和 Composer 自动加载机制 - 如果你项目自定义了
autoload配置（比如删掉了psr-4段或加了冲突的exclude-from-classmap），会导致该路径被跳过 - 运行
composer show psr/cache，输出中应包含versions : * 3.0.0, 2.0.0，若只显示dev-main，说明版本约束没生效
真正容易被忽略的是：装上 psr/cache 只是拿到了接口契约，你仍需选一个具体实现（比如 symfony/cache 或 laravel/framework 内置缓存），否则所有 new CacheItemPool() 都会失败。接口本身从不实例化。
