provide字段必须写在被require的包中，根项目中声明无效；它仅影响依赖解析，不负责自动加载，且多个包提供同一虚拟包时选择不可控。
provide字段必须写在被require的包里，根项目中写无效
Composer只在解析依赖图时读取provide字段，且仅从你require的第三方包（或私有包）的composer.json中提取。你在自己项目的根composer.json里加"provide": {"psr/log-implementation": "*"}，Composer会直接忽略——它不认为根项目能“提供”能力给其他包。
常见错误包括：
- 把
provide误写进根项目，调试半天发现根本没参与依赖解析 - 包已发布但未上传到仓库（如只本地
pathrepo），Composer install时压根不会读它的composer.json - 拼错虚拟包名，比如写成
psr/log（这是接口规范包），实际该写psr/log-implementation
provide不是自动加载开关，类路径和autoload仍需单独配
provide只影响依赖解析阶段：当某个包声明"require": {"psr/log-implementation": "^1.0"}，而你的包在provide里写了"psr/log-implementation": "*"，Composer就认为这个require已被满足，不再安装Monolog等实现。
但它完全不负责类的加载。如果你的包里实现了PsrLogLoggerInterface，但composer.json里没配"autoload": {"psr-4": {"MyOrg\Log\": "src/"}}，运行时照样报Class not found。
实操要点：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 先确保
autoload配置正确，能通过composer dump-autoload -d vendor/myorg/my-log-driver验证类可加载 - 再检查
provide字段是否与生态约定一致（如psr/http-client-implementation、ext-gd） - 别指望
provide能绕过require-dev里的测试依赖——它只管require链
多个包提供同一虚拟包时，顺序不可控，别依赖“谁先被选中”
如果A包和B包都声明了"psr/cache-implementation": "*"，而你的项目同时require了A和B，Composer会任选其一来满足上游包的require，不保证是A还是B。这种非确定性在CI环境尤其危险。
更现实的问题是版本冲突：
- A包提供
"psr/cache-implementation": "^2.0"，B包提供"^3.0" - 上游包要求
"psr/cache-implementation": "^2.0 || ^3.0"→ 没问题 - 上游包只要
"^2.0"→ Composer可能挑中B包，然后报错“B不满足^2.0”
所以真正可控的做法是：在根项目require里明确指定你要的那个实现包，而不是靠provide让Composer“猜”。provide更适合做兼容层声明，不是调度器。
ext-*类提供要小心PHP版本和扩展ABI兼容性
写"ext-redis": "7.4.0"看似简单，但实际运行时可能崩：
- PHP 8.0+ 的
ext-redisv5.x 和 PHP 7.4 的 v4.x ABI不兼容，即使版本号标对，php -m | grep redis显示已加载，运行时仍可能Segmentation Fault -
ext-*的版本号应严格对应php -i | grep "redis version"输出，而不是Composer包的版本 - 若你封装的是C扩展桥接层（比如用FFI调用
hiredis），provide无法表达底层库约束，得靠conflict或文档警告
最稳妥的写法是"ext-redis": "*" + 明确文档说明支持的PHP/扩展组合，别试图用版本号“精确控制”运行时行为。
