composer show --suggests 是唯一靠谱的批量查看方式：自 Composer 2.2 起，该命令仅读取 vendor/ 下已安装包的 composer.json，清晰输出包名、建议包及描述，无远程查询，真实反映当前环境。

composer show --suggests 是唯一靠谱的批量查看方式

Composer 没有 composer suggests 这个命令，也不存在 composersuggests（注意拼写）——这些是常见误传。自 Composer 2.2 起，真正能一次性列出所有已安装包建议项的，只有 composer show --suggests。

• 它只读取 vendor/ 下已安装包的 composer.json，不查远程数据，结果完全反映你当前环境的真实状态
• 输出格式清晰：包名 + 冒号 + 建议包 + 描述，比如 guzzlehttp/guzzle suggests: psr/log: To enable logging middleware
• 如果没输出，说明你项目里没有任何已安装包定义了 suggests 字段（不是命令错了，是真没有）

想查单个包的建议？用 composer show 加包名

当你只关心某个特定包（比如刚装完的 monolog/monolog）推荐了什么，composer show monolog/monolog 最直接。它的输出末尾会明确标出 suggests: 字段。

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• 注意：必须输入完整包名，composer show monolog 会报错，因为 Composer 不支持模糊匹配
• 如果该包尚未安装（比如你只是在选型），就得去 GitHub 或 Packagist 页面翻它的 composer.json，composer show 查不到未安装的包
• 有些包把 suggests 写成多行或带换行符，终端显示可能被截断；这时可直接打开 vendor/monolog/monolog/composer.json 查原始内容

别信“自动安装建议”的说法，suggests 纯属提示，不参与任何依赖逻辑

suggests 字段连 Composer 的依赖解析器都懒得看一眼。它不出现在 composer.lock，不进 vendor/composer/installed.json，也不影响 composer install 是否成功。

• 即使你删掉整个 vendor 重装，只要没手动 composer require，那些“建议包”就永远不会出现
• --no-suggest 参数只屏蔽安装后那段灰色提示文字，对实际行为零影响——它不是开关，只是“静音键”
• 如果你看到某功能报错说“Class not found”，而错误堆栈指向一个 suggests 里的包，那说明你的代码逻辑已经强依赖它了，这时候它早就不该待在 suggests 里，而该进 require

想让建议变成真实依赖？只能手动加进 require 或用插件辅助

没有魔法命令能“一键安装所有建议”。真要启用某项增强功能，最终一步永远是人来决定并执行 composer require。

• 最稳妥的做法：从 composer show --suggests 输出里复制你想用的包名（如 symfony/console），再运行 composer require symfony/console
• 如果嫌手动太碎，可用社区插件 boekkooi/composer-suggest-plugin，它会在 composer update 后交互式询问是否安装建议项
• 注意插件兼容性：它对 Composer 2.5+ 支持尚不稳定，某些版本会跳过提示直接静默失败——别全信文档，先本地试一次再说

容易被忽略的一点：suggests 的描述文字里常藏着关键线索。比如写的是 “to auto-register the service provider”，那就意味着装完还要跑 php artisan vendor:publish；如果只写 “for logging support”，大概率装完就能用。别光看包名，得读清楚那句短描述在说什么。