虚拟包是通过provide字段声明能力而非真实包，仅用于语义占位与兼容协调；必须小写连字符命名、配合法语义版本，不可require或autoload，常与conflict/replace配合解决依赖冲突。
虚拟包（virtual package）不是真实发布的包，而是通过provide字段在composer.json中声明“我提供了某个接口或能力”，让其他包能把它当作依赖来约束——但你不能composer require它，也不能autoload它的类。 它只起语义占位和兼容性协调作用，写错会导致依赖解析失败、自动发现跳过、甚至 Laravel 包完全不加载。
什么时候必须用provide而不是require
当你写的扩展包要适配多个框架版本，又不想硬依赖某个具体实现时才用。比如：你的日志桥接器同时支持 psr/log 和 monolog/monolog，但不想强制用户装 monolog；或者你封装了一个缓存抽象层，想声明“我提供 cache-implementation 能力”，让下游项目自由选 laravel/framework 或 symfony/cache。
- 错误做法：
"require": {"cache-implementation": "*"}—— 这个包根本不存在，Composer 会报could not be resolved - 正确做法：
"provide": {"cache-implementation": "1.0"}—— 告诉 Composer：“我实现了这个能力”，下游可用"require": {"cache-implementation": "^1.0"}约束 - 常见误用：把
illuminate/support放进provide—— 它是真实可安装的包，应放require或require-dev
provide字段怎么写才不被 Composer 忽略
Composer 只认 provide 字段里的键为“虚拟包名”，值为版本号（任意合法语义版本，如 "1.0"、"dev-main"），但不会校验它是否真实存在。关键点在于：它必须和下游项目的 require 完全匹配（包括大小写、连字符）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 必须写成小写+连字符格式，例如：
"provide": {"psr-container-implementation": "2.0"}，不能写成"PSR-Container-Implementation" - 版本号建议用稳定版（如
"1.0"），避免"*"或"dev-master"—— 后者会让依赖解析器无法收敛 - 如果同时提供多个能力，可以写多组：
"provide": {"psr-log-implementation": "3.0", "psr-cache-implementation": "3.0"} - 注意：Laravel 自动发现机制（
package:discover）完全不读取provide，它只看type和autoload
和conflict、replace混用时的坑
虚拟包常和 conflict 搭配解决冲突，比如你包里自带一个轻量缓存实现，想阻止用户再装 doctrine/cache；或用 replace 声明替代关系。但三者逻辑不同，顺序一错就失效。
-
conflict是“禁止共存”："conflict": {"doctrine/cache": " 表示装了你的包就不能装旧版 doctrine/cache -
replace是“我就是它”："replace": {"psr/simple-cache": "1.0.1"}表示你这个包等价于那个包，Composer 会跳过安装原包 -
provide+conflict组合最常见："provide": {"psr-simple-cache-implementation": "1.0"}, "conflict": {"psr/simple-cache": "*"}—— 表示“我提供能力，且不允许原包存在” - 错误顺序：
"conflict"写在"provide"前面没影响，但若"replace"和"provide"声明同一名称，Composer 会优先按replace处理，provide形同虚设
虚拟包本身没有代码、不参与自动加载，provide 字段只是给 Composer 解析器看的元信息。最容易被忽略的是：它对本地开发调试完全无效——你在主项目里用 path 方式引入包时，Composer 不会重新评估 provide 关系，只有发布到 Packagist 并被别人 require 时才真正起作用。
