Composer虚拟包是通过replace或provide声明的逻辑占位符，非真实包；replace彻底替代目标包及其依赖，provide仅声明实现某接口能力供依赖解析识别。
什么是 Composer 虚拟包（virtual package）
虚拟包不是真实存在的包，而是通过 replace 字段在 composer.json 中声明的“占位符”，用来告诉 Composer：“这个包名已被本项目或另一个包逻辑上替代了”。它不下载代码、不生成文件，只参与依赖解析。常见于 Laravel 的 laravel/framework 替换 psr/log 或 symfony/console 等接口包，也用于私有组件抽象（如用 mycorp/core-contracts 替代多个具体实现）。
用 replace 消除冲突而非掩盖问题
很多人误把 replace 当成“跳过安装”的快捷方式，结果在 CI 构建时因依赖图断裂而失败。正确做法是：仅当某包确实被当前项目完全接管（比如你重写了全部 psr/container 接口实现并注册了自己的容器），才用 replace 声明替代关系。
-
replace不会阻止其他包 require 同名包——它只是让 Composer 在解析时认为“该包已满足”，所以必须确保你的实现 100% 兼容原包契约（方法签名、返回类型、异常行为） - 若仅想跳过某个 dev-only 包，应改用
conflict+--ignore-platform-req，而不是replace - 替换 PSR 接口包（如
psr/http-message）时，务必检查所有依赖是否真的只依赖接口——有些包会在src/里硬写new \GuzzleHttp\Psr7\Request()，这时replace无效，得靠provide或重构
provide 比 replace 更安全的场景
当你提供的是能力（capability）而非身份（identity）时，优先用 provide。例如：一个轻量 CLI 工具声明 "provide": {"psr/log-implementation": "1.0"}，表示“我实现了 PSR-3 日志接口”，但不声称自己是 psr/log 包本身。这样既允许其他包正常 require psr/log，又能让依赖它的包（如 monolog/monolog）知道已有实现可用。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
provide不影响依赖树结构，不会导致 “Package X is abandoned” 报错 - 它常和
require配合："require": {"psr/log": "^1.0"}, "provide": {"psr/log-implementation": "1.0"} - CI 构建中若出现
could not find package psr/log-implementation，说明某依赖写死了 require 具体实现包（如monolog/monolog），此时需确认是否真要强制绑定实现
构建时如何验证虚拟包是否生效
运行 composer show --tree 或 composer depends --tree vendor/package-name 可直观看到虚拟包是否被识别为“已满足”。但更关键的是检查 vendor/composer/installed.json —— 虚拟包不会出现在该文件里，而真实安装的包会。如果你发现某 replace 声明没起作用，大概率是：
-
composer.json放错了位置（不在根目录，导致命令未读取该配置） - 拼写错误：比如写成
"replaces"或"provides"（正确字段名是replace和provide） - 目标包版本不匹配：
"replace": {"foo/bar": "2.0.0"}无法满足require: {"foo/bar": "^2.1"} - 用了
composer update --with-dependencies却没加--no-install，导致 Composer 尝试下载被 replace 的包并报 404
最易被忽略的一点：虚拟包只影响依赖解析阶段，不影响自动加载。即使你 replace 了 psr/http-message，仍需确保自己的 MessageInterface 类能被正常加载——这取决于你的 autoload 配置是否覆盖对应命名空间。
