provide字段必须严格匹配目标包完整包名（含vendor/name、大小写），仅声明替代关系而非功能；需配合replace才能安全替代原包，虚拟包不可被require，且不解决运行时类加载问题。

provide字段写错包名会直接导致依赖安装失败

Composer 的 provide 字段不是“声明我有这个功能”，而是“声明我**替代**某个真实包”。如果填的包名拼错、大小写不一致、或者用了不存在的包名（比如 monolog/monolog 写成 monolog/logger），composer install 会静默跳过该提供关系，但下游依赖若明确 require 了被提供的包，就会报 Root composer.json requires monolog/monolog ^2.0, found monolog/monolog[...] but these were not loaded 这类错误——本质是 Composer 没认出你“提供了它”。

• 必须严格匹配目标包的完整包名（包括 vendor/name 格式），区分大小写
• 不能用通配符或模糊匹配，provide 只支持精确字符串
• 常见翻车点：把 psr/log 写成 psr/log-interface（后者早已废弃）
• 如果提供的是 PSR 接口，优先查官方 packagist 页面确认当前标准包名

provide + replace 组合才能安全替代一个包

只靠 provide 不足以让 Composer 把你的包当原包用。比如你想用自研日志组件替代 monolog/monolog，仅写 "provide": {"monolog/monolog": "2.10.0"} 是不够的：Composer 仍可能同时拉取 monolog/monolog 和你的包，造成冲突或重复加载。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 必须搭配 replace 字段，例如："replace": {"monolog/monolog": "*"}
• replace 告诉 Composer：“别装这个包了，我全权代替”；provide 则说明“我实现了它的契约（如接口）”
• 版本号在 provide 中建议写具体兼容版本（如 "2.10.0"），避免误导其他依赖对 API 的预期
• 若你的包不完全兼容原包（比如缺某些方法），不要写 "*"，否则下游调用失败时很难定位

虚拟包无法被 require，只能被 provide/replaced

所谓“虚拟包”，是指 packagist 上根本不存在、仅靠 provide 声明出来的包名。它没有源码、没有 dist、没有 autoload，只是一个占位符。这意味着：

• 你不能在别的项目里直接 composer require your-virtual-package-name —— 会报 Could not find package your-virtual-package-name
• 它只在当前项目的 composer.json 中通过 provide 被“释放”出来，供本项目中其他 require 它的依赖识别
• 典型用途：统一声明一组接口实现，比如多个组件都 provide: {"psr/http-client-implementation": "1.0"}，上层框架只需 require: {"psr/http-client-implementation": "^1.0"}
• 如果你希望别人能主动引入你的虚拟包，得把它做成真实包（哪怕只有空 composer.json 和 autoload），再用 provide 声明能力

PSR 接口提供必须匹配实际实现的 autoload

写了 "provide": {"psr/http-message": "1.0"}，不代表 Composer 就能自动加载 Psr\Http\Message\RequestInterface。如果 autoload 没正确映射到这些类，运行时仍会报 Class 'Psr\Http\Message\RequestInterface' not found。

• 先确认你是否已通过 require 或 autoload-dev 加载了对应 PSR 包（如 psr/http-message），或者自己实现了全部接口并注册了 autoloader
• 如果只是“提供能力”但不包含实现，应改用真实依赖：比如 require psr/http-message，再在 provide 中声明你“兼容它”
• 检查 composer dump-autoload -o 后生成的 vendor/composer/autoload_psr4.php，确认 PSR-4 映射是否覆盖了 Psr\ 命名空间
• 别指望 provide 自动解决类加载问题——它只影响依赖解析阶段，不参与 autoloading

实际用起来最常卡住的地方，是以为 provide 能绕过类加载或替代 require 行为。它只在 Composer 解析依赖图时起作用，一到运行时，所有类路径、命名空间、自动加载规则，还得老老实实按 PSR 标准来。