provide 声明本包可替代指定虚拟包（如 psr/cache-implementation），用于满足其他包的 require 依赖；须置于 composer.json 顶级 provide 对象中，键为标准虚拟包名，值为版本号（如 "*"），根项目声明无效。
Composer 的 provide 字段到底在提供什么？
provide 不是“发布包”，也不是“替代依赖”，它声明的是：「我这个包，能当另一个包来用」。典型场景是虚拟包（virtual package）——比如你写了个自定义的缓存驱动，想让它被 Laravel 的 cache 接口识别，就得告诉 Composer：“我提供了 psr/cache-implementation”。Composer 本身不校验实现是否合规，只靠这个字段让其他包（比如框架）通过 require 声明“需要任意一个 cache 实现”时，能顺利安装你。
怎么写 provide 才不会被忽略？
必须写在 composer.json 的顶级 provide 字段里，值为对象，键是包名，值是版本号（可为 *）。常见错误包括：
- 写成
requires或replaces—— 完全无效 - 包名拼错，比如写成
psr/cache（这是接口规范包），实际要提供的是psr/cache-implementation - 版本写成
"^3.0"却没实现对应 PSR，Composer 不报错，但运行时可能崩
正确示例：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
{
"name": "myorg/my-cache-driver",
"provide": {
"psr/cache-implementation": "*",
"ext-redis": "7.4.0"
}
}
哪些包名值得提供？看主流生态怎么约定
不是随便起名，得和现有生态对齐，否则没人认。高频有效的虚拟包名有：
-
psr/log-implementation：任何实现了Psr\Log\LoggerInterface的包都该提供它 -
psr/http-client-implementation：Guzzle、Symfony HttpClient 都提供这个 -
ext-*类（如ext-gd,ext-mbstring）：用于声明扩展可用性，供其他包做条件依赖 - 框架私有约定名，如
laravel/framework并不真正发布，但某些包会require它来触发 Laravel 特定逻辑（需配合replace使用，provide单独不够）
为什么装了包，provide 还是不生效？
最常被忽略的点：Composer 只在 install 或 update 时读取 provide，且仅用于解决依赖冲突或满足 require 条件。如果你只是本地开发、没把它发布到仓库、也没被其他包 require，那它就纯粹是个声明，不会触发任何行为。另外注意：
- 根项目（即你的
composer.json）里的provide字段会被完全忽略 —— 只有被 require 的包才能提供东西 - 如果两个包都提供同一个虚拟包（比如都提供
psr/cache-implementation），Composer 默认选第一个解析到的，不保证顺序 -
provide不影响自动加载，类文件路径、autoload配置仍需单独配好
真要用起来，得有人明确 "require": {"psr/cache-implementation": "^1.0"}，否则它就躺在那里，安静又孤独。
