Composer 不会自动安装 suggest 字段声明的包，它仅为文档提示，不参与依赖解析、版本检查或 lock 文件生成；需手动执行 composer require 才能生效。
Composer 不会自动安装 suggest 字段里声明的包，它只是提示信息，不是依赖声明。 你看到 "suggest" 出现在某个包的 composer.json 里，比如 "monolog/monolog": "For logging support"，这不代表 Composer 会帮你装 monolog/monolog——它连解析都不会解析，更不会检查版本兼容性或写入 composer.lock。
为什么 suggest 不触发安装
suggest 是纯文档性质的字段，设计初衷是让包作者告诉使用者：“如果你需要 XX 功能，可以考虑配合使用这个包”。它不参与依赖图构建，也不被 Composer 的解析器读取。
- 运行
composer install或composer update时，suggest内容会被忽略，控制台可能打印一行灰色提示（取决于 verbosity 级别），但不会中断流程 - 即使你本地没装被 suggest 的包，也不会报错；反之，装了也不会被自动启用或集成
- 它和
require、require-dev、conflict等真正影响解析的字段完全不在一个处理层级
suggest 和 replace/provide 容易混淆的点
有人看到 suggest 就以为“类似弱依赖”，甚至想用它绕过冲突——不行。真正能影响依赖解析的是 provide（声明本包提供了某虚拟包能力）或 replace（声明本包替代另一个包）。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
"provide": {"psr/log-implementation": "1.0"}会让其他包认为“日志实现已就绪”，从而跳过对monolog/monolog的硬依赖 -
"suggest"连这种语义都没有，它只是字符串，不参与任何逻辑判断 - 如果你发现某包靠
suggest描述的功能实际是必须的，说明文档和实现脱节，该提 issue 或换包
怎么让 suggest 的包真正生效
想用上被 suggest 的包，你得手动操作——Composer 不会替你做决定，也不会猜你需要什么。
- 确认用途：先看提示文字（如 “For AWS S3 integration”），判断是否真需要这个扩展能力
- 手动 require：运行
composer require vendor/package-name，它才会进入require区域并参与解析 - 注意版本兼容：被 suggest 的包可能有 PHP 版本、扩展（如 cURL、openssl）或其它依赖要求，要自己核对
- 有些包在
suggest里写的是可选驱动（如"ext-pdo_mysql": "For MySQL database support"），这类不是 Composer 包，而是 PHP 扩展，得靠系统安装，不是composer require能解决的
真正容易被忽略的是：suggest 字段从不校验真实性。它可能指向一个早已废弃的包、拼写错误的名称，甚至根本不存在的 vendor 名——Composer 不会查，也不会警告。看到建议，先 composer search 或去 Packagist 确认是否存在且维护活跃，再动手装。
