composer suggest 是只读提示功能，仅列出 composer.json 中 "suggest" 字段内容，不安装、不验证、不递归，输出完全依赖包作者是否手动填写该字段。
composer suggest 是个只读提示，不安装也不修改任何东西
它只是把 composer.json 里 "suggest" 字段的内容列出来，告诉你“作者建议你顺手装这几个包”，比如日志驱动、缓存适配器、测试工具等。它不会检查这些包是否已安装，也不会验证版本兼容性，更不会自动执行 require —— 完全是个“温馨提示”功能。
常见错误现象：composer suggest 执行后没输出，或只显示空行。这不是命令坏了，而是当前项目 composer.json 根本没写 "suggest" 字段，或者依赖的包（如 monolog/monolog）在自身 composer.json 中没声明建议项。
- 该命令无参数，不支持
--dev、--no-dev或版本过滤 - 输出内容完全取决于各包维护者是否主动填写了
suggest，不是 Composer 自动生成的 - 无法通过
composer suggest判断某个包“该不该装”，它没有上下文逻辑（比如是否启用某特性）
怎么看到真正有用的建议？得看 require 的包自己写了啥
composer suggest 的实际价值，几乎全部来自你已安装的第三方包——比如装了 guzzlehttp/guzzle，它可能在自己的 composer.json 里写："suggest": {"ext-curl": "Required for sending HTTP requests"}；装了 symfony/console，可能建议 symfony/event-dispatcher 来扩展命令生命周期。
所以真正要查建议，得先确认目标包是否已出现在 vendor/ 中，再翻它的源码根目录下的 composer.json。直接运行：
cat vendor/guzzlehttp/guzzle/composer.json | grep -A 5 '"suggest"
比依赖 composer suggest 更可靠。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer suggest不递归扫描子依赖，只显示顶层require包的建议 - 如果某个包用了
"suggest"但指向一个已废弃的包（如phpunit/phpunit:~4.0），它照样照打，不会警告 - 某些框架包（如 Laravel）根本不用
suggest，而是靠文档或artisan命令提示扩展包，别指望这里能捞到
想让自己的包显示建议？必须手动写进 composer.json
如果你是包作者，想让用户看到 “建议安装 foo/bar 来启用 XX 功能”，就得在你自己包的 composer.json 里明确定义：
{
"name": "myorg/mylib",
"suggest": {
"monolog/monolog": "Enables logging support",
"ext-redis": "Required for Redis cache adapter"
}
}
注意两点：
-
suggest是对象结构，键是包名或扩展名，值是说明文字，不能写成数组 - 字段名必须小写
suggest，写成Suggest或recommends都无效 - 这个字段只影响
composer suggest输出和 Packagist 页面展示，不影响install或update行为
替代方案：用 status + show 组合判断实际缺失
比起被动等 suggest 提示，更实用的做法是主动检查环境是否满足运行前提。例如：
- 运行
composer status查看本地修改，确认没漏改 autoload 或脚本 - 用
composer show monolog/monolog看它有没有列出suggest字段（部分版本会显示） - 检查扩展是否加载：
php -m | grep curl，比依赖“建议”更直接
真正容易被忽略的是：suggest 从不校验 PHP 版本、扩展是否存在、或配置是否启用。它只负责“说出来”，至于听不听、装不装、能不能用——全在你自己。
