Composer中provide和suggest字段在包分发时的正确写法（开发规范）-composer-PHP中文网

provide字段必须位于composer.json根级且键名严格为"provide"，用于声明虚拟包实现以参与依赖解析；suggest字段仅作安装提示，值须为字符串且不参与依赖计算。

composer中provide和suggest字段在包分发时的正确写法（开发规范）

provide字段必须写在根级，且键名要严格匹配虚拟包规范

provide不是随便起名的字段，它直接参与依赖解析——Composer靠它判断“这个包能不能满足其他包的require”。写错位置或拼错名字，等于没写。

常见错误：provide被塞进require-dev里、写成provides（少个e）、把psr/cache-implementation写成psr/cache或psr-cache-implementation。这些都会让下游包无法识别你的实现。

必须放在composer.json最外层，和name、require同级
键必须是标准虚拟包名，如psr/log-implementation、ext-redis、laravel/framework（后者属框架私有约定）
值只能是版本号字符串，支持"*"、"2.0"、"^3.0"，但不校验你是否真实现了对应接口——填错只会在运行时崩
多个提供项用对象平铺，不能嵌套或用数组

suggest字段只接受纯字符串描述，禁止任何版本约束或布尔值

suggest根本不会被Composer解析为依赖，它只是终端里一闪而过的灰色提示。但格式错一点，就会导致composer install直接失败。

典型翻车点："monolog/monolog": "^3.0"会被当成非法JSON值；"ext-redis": true会触发解析错误；"guzzlehttp/guzzle": ["For HTTP client"]数组写法直接中断流程。

Discussion Composer

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

下载

键必须是合法包名或ext-前缀扩展名，如ext-gd、phpunit/phpunit
值只能是字符串，且建议带动词短语说明用途，比如"To enable Redis-backed cache driver"，别写"Optional"或"Recommended"
包名大小写、斜杠方向必须完全一致：guzzlehttp/guzzle ≠ guzzle/guzzle，psr/cache ≠ psr/cache-implementation
所有suggest条目仅在该包首次安装或更新后输出一次，后续composer require其他包不会重刷

provide和suggest混用时，功能边界必须清晰

有人想用suggest引导用户装一个provide了某虚拟包的驱动，这没问题；但千万别反过来：用provide去“替代”本该由suggest承担的文档提示职责。

比如你写了"provide": {"myorg/feature-flag": "1.0"}，但没人require这个虚拟包——那这行代码毫无意义，还可能误导维护者。

provide用于解决“依赖能否满足”，面向Composer解析器；suggest用于回答“装了能干啥”，面向开发者眼睛
如果某个能力是可选但需手动启用（如加一行use或改配置），用suggest + README说明
如果某个能力是抽象契约的一部分（如实现Psr\Http\Client\ClientInterface），必须用provide声明，否则依赖它的包装不上
不要在同一个包里既provide又suggest同一项——比如"provide": {"ext-redis": "*"}和"suggest": {"ext-redis": "Enable Redis cache"}冗余且易维护错