根本原因是Composer不通过Packagist或repositories解析虚拟包（如ext-redis），而依赖本地PHP扩展加载状态或config.platform显式声明；若php -m未列出或platform版本不匹配，就会报“Could not find package”。
找不到 Composer 虚拟包（比如 ext-redis、phpunit/phpunit 这类不对应真实 Git 仓库的“伪包”），根本原因不是网络或权限，而是 Composer 默认不解析它们的元数据——它只在明确启用虚拟包支持、且配置了正确源类型时才尝试匹配。
为什么 composer require ext-redis 直接报 “Could not find package”
Composer 对虚拟包（ext-*、lib-*、php 等）的处理逻辑和普通包完全不同：它不查 Packagist，也不走 repositories 数组，而是依赖本地 PHP 环境 + composer.json 中的 provide 声明 + 全局 platform 配置。一旦缺失任一环节，就静默跳过，直接报“not found”。
常见错误现象：
- 运行
composer require ext-redis报错，但php -m | grep redis显示已加载 -
composer show列不出任何ext-*包，哪怕扩展已启用 - 私有项目里 require 了
phpunit/phpunit，却提示找不到，而实际安装的是phpunit/phpunit的某个子包（如phpunit/php-code-coverage）
关键点：
- 虚拟包不能靠
repositories声明来“添加”，它们必须由当前 PHP 环境或config.platform显式提供 -
ext-redis这类包名是硬编码规则，大小写敏感，ext-Redis或ext_redis都无效 - Composer 2.5+ 开始，
php版本也被当作虚拟包处理，若composer.json中写了"php": "^8.1"，但本地是 8.0，也会导致依赖解析失败（看似“not found”，实为平台不兼容）
composer.json 里怎么正确声明虚拟包依赖
虚拟包只能通过 require 字段引用，但必须配合 config.platform 或确保扩展真实可用。不能用 repositories 或 minimum-stability 控制它们。
实操建议：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 确认扩展已加载：
php -m | grep redis（Linux/macOS）或php --ri redis（更准确） - 如果是在 CI 或容器环境，PHP 扩展可能未安装，需先执行
docker-php-ext-install redis类命令 - 若想绕过本地检查（例如开发机没装 redis，但 CI 有），在
composer.json的config下加："platform": { "ext-redis": "5.3.7" }注意版本号必须是真实扩展的版本（可用php --ri redis | grep Version查），填*或留空会失效 - 不要在
repositories里加{"type":"package",...}去“模拟”虚拟包——Composer 不识别这种写法，会静默忽略
为什么 composer search ext-redis 搜不到，但 composer show 又能列出？
composer search 只查 Packagist 元数据索引，而虚拟包根本不在 Packagist 上注册；composer show 显示的是当前环境已满足的 provide 条目（来自 platform 或已安装扩展），二者查询路径完全隔离。
所以：
-
composer search ext-*永远为空，这是正常行为，不是 bug -
composer show -p（带-p参数）才能列出所有已提供的虚拟包，包括ext-*、lib-*、php - 若
composer show -p里没有你要的ext-xxx，说明要么扩展没启用，要么platform没配对，别指望换源或清缓存解决
CI/CD 中虚拟包“突然找不到”的排查顺序
这类问题多发生在部署环境与本地不一致时，重点不是改配置，而是对齐环境。
按优先级检查：
- 确认 PHP CLI 版本和扩展是否与
composer.json中require.php和config.platform完全匹配（版本号精确到小数点后一位） - 检查 CI 镜像是否用了
php:alpine这类精简版——它默认不带ext-zip、ext-gd等，需显式安装 - 运行
composer diagnose，它会明确告诉你哪些ext-*缺失，比报错信息更直接 - 避免在
composer.json中混用config.platform.php和require.php：前者是“假装有”，后者是“必须满足”，冲突时 Composer 优先按require校验
最常被忽略的一点：虚拟包不参与锁文件生成，composer.lock 里永远看不到 ext-* 条目——所以即使 lock 文件没问题，部署时 PHP 环境变了，照样失败。
