replace仅在依赖解析阶段做名字映射，不替换文件或类；必须确保被替换包的所有接口已实际实现，且需配conflict防运行时冲突，否则会fatal error。
composer.json 里用 replace 声明虚拟包，不是为了“替代真实代码”
replace 字段在 Composer 中本质是告诉依赖解析器：“当其他包 require 这个包名时，请把我当成它”。它不复制、不重写、不注入任何类——只是在依赖图里做一次名字映射。常见误用是把 replace 当成 polyfill 或 adapter 的替代方案，结果运行时报 Class not found。
典型错误示例："replace": {"psr/http-message": "self.version"}，但项目里根本没实现 PsrHttpMessageRequestInterface。Composer 解析通过了，autoload 却找不到类。
- 必须确保被 replace 的包名，其所有公开接口（类、接口、函数）已在你的代码中完整提供，或由其他已安装包兜底
- replace 不会触发自动加载规则变更，
autoload段仍需独立配置 PSR-4 或 files - 如果只是想让多个框架（如 Laravel、Hyperf、ThinkPHP）都能用你的工具类，优先考虑用抽象层 + 适配器模式，而不是靠 replace 欺骗 Composer
用 virtual package 解耦框架强依赖，关键在命名空间与 autoloading
真正起作用的不是 replace，而是你如何组织代码和声明自动加载。比如你想让一个日志桥接器同时适配 psr/log 和 monolog/monolog，不要试图 replace monolog，而是：
- 在
src/下按 PSR 标准实现PsrLogLoggerInterface，并提供MonologAdapter类封装原生 Monolog 实例 -
composer.json中只写"psr/log": "^3.0"到 require，不碰monolog/monolog - autoload 使用
"psr-4": {"MyPackage\Log\": "src/Log/"}，不混入框架私有命名空间（如IlluminateLog*）
这样下游项目无论用 Laravel 还是 Hyperf，只要它们本身支持 PSR-3，就能直接 new 你的 LoggerInterface 实现，无需任何 replace。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
replace + conflict 组合才能防止框架混用导致的运行时崩溃
有些场景下，你确实需要阻止用户把你的包和某个框架版本一起装——比如你的扩展只兼容 ThinkPHP 6.x，但用户又偷偷 require 了 TP5 的旧组件。这时 conflict 比文档警告管用得多：
-
"conflict": {"topthink/framework": "=7.0.0"}明确封死不兼容区间 - 搭配
"replace": {"mycompany/tp-bridge": "self.version"}，让使用者能显式 require 这个虚拟包名，而非直接依赖框架内部类 - 注意 conflict 是硬性拦截：哪怕该包没被直接 require，只要被某个间接依赖拉进来，Composer 就会拒绝 install
这种组合在发布多框架适配 SDK 时最实用，比如 alibabacloud/client 就用类似方式隔离不同 PHP SDK 版本间的冲突。
vendor/autoload.php 不认虚拟包，运行时行为完全取决于实际加载的类
Composer 安装阶段认 replace，但 vendor/autoload.php 只看文件路径和命名空间。你声明了 "replace": {"laravel/framework": "10.0.0"}，不代表 IlluminateSupportFacadesDB::class 就会自动存在。
最容易被忽略的一点：每次切换框架目标（比如从 Laravel 改为 Hyperf），必须删掉 vendor/ 和 composer.lock 重新 install。否则 autoload_static.php 里可能残留旧框架的类映射，导致新框架下 class_exists('App\Providers\AppServiceProvider') 返回 false，但报错却指向完全无关的文件。
