Composer 的 suggests 默认不装，因为它是作者标注的非必需可选建议项，不参与依赖解析、不写入 composer.lock，需手动通过 composer require 显式安装。
Composer 的 suggests 为什么默认不装？
因为 suggests 是作者写的“锦上添花”提示，不是功能必需项——比如 monolog/monolog 建议你装 ext-amqp 来支持 RabbitMQ 日志传输，但没它照样能用文件或 Stdout。Composer 严格区分“必须”和“可选”，所以从不自动拉取 suggests 列表里的包。
常见错误现象：composer install 后发现某功能报错说“Class not found”，一查文档才发现它依赖某个被列在 suggests 里的驱动包，但你根本没装。
-
suggests不参与依赖解析，不会影响composer update的版本计算 - 它不写进
composer.lock，也不触发自动加载注册 - Packagist 页面和
composer show vendor/package都能直接看到该字段
怎么手动装一个 suggests 里的包？
最稳、最透明的方式：把它加进你项目的 require 或 require-dev，变成正式依赖。
实操建议：
- 先查目标包的
composer.json（GitHub 或 Packagist 页面），找到类似"suggests": {"ext-redis": "For Redis cache support"}的条目 - 运行
composer require ext-redis—— 注意：扩展名（如ext-redis）不能直接require，得装对应 PHP 扩展；如果是包名（如symfony/cache），就直接composer require symfony/cache - 若建议的是测试工具，加
--dev：例如composer require phpunit/phpunit:^10 --dev
这样做的好处是：下次 composer install 或 CI 流水线执行时，它一定存在，不会因环境差异漏掉。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
有没有插件能自动问你要不要装 suggests？
有，boekkooi/composer-suggest-plugin 就是专干这事的，但它不是“全自动”，而是交互式提示。
使用前注意：
- 安装命令是
composer global require boekkooi/composer-suggest-plugin（全局插件） - 之后每次
composer install或composer update，它会列出所有未安装的suggests并等你按 y/n 选择 - 不支持 Composer 2.5+ 的某些新钩子机制，部分用户反馈提示失效——遇到就别硬扛，退回手动
require - 它不会帮你解决版本冲突，比如两个包都
suggest不同版本的guzzlehttp/guzzle，还得你自己拍板
怎么确认某个 suggests 其实已经“转正”了？
有些包作者后期把关键能力从“可选建议”挪进了 require，比如早期 laravel/framework 只 suggest doctrine/dbal，但从 v9 开始它成了硬依赖。这时候你还盯着 suggests 看，就容易误判。
快速验证方法：
- 打开该包最新版的 Packagist 页面 → 点 “Source” 跳 GitHub → 查看其
composer.json的require字段 - 搜一下它的 CHANGELOG 或升级指南，关键词是 “
require”、“dropped suggests”、“now required” - 运行
composer why-not vendor/package:version，有时会反向暴露哪个包挡着你装它——那很可能就是它已被其他依赖“带进来了”
真正容易被忽略的点是：很多 suggests 其实对应的是“桥接包”（bridge），比如 symfony/monolog-bundle 本身不干活，但装了它，就会自动拉取 monolog/monolog 和相关 handler。别只盯着底层库，先看有没有现成的 bundle 或 integration 包。
