Composer 的 suggests 字段仅作静态提示，不触发自动安装或影响依赖解析；它在 install/update 后命令行输出建议内容，需配合文档、脚本或工具链提升可见性与落地效果。
Composer 的 suggests 字段本身**不触发自动安装**，也不影响依赖解析，它只是个静态提示——想靠它“引导用户装关联包”，必须配合文档、脚本或工具链，否则基本没人会注意到。
什么是 suggests？它到底干啥用的
它是 composer.json 里的一个可选字段，类型为对象，键是包名，值是说明性字符串。Composer 在 install 或 update 结束后，会把所有已安装包的 suggests 合并打印出来（前提是没加 --quiet）。
关键点：
- 仅对当前包的
suggests生效，不会递归检查建议包自身的suggests - 只在命令行输出，不写入
vendor/autoload.php，不修改任何运行时行为 - 如果建议的包已被安装，也不会高亮或做任何特殊标记
怎么写才让用户真正看到并理解建议
光写 "monolog/monolog": "用于日志记录" 效果很差。要提升可见性，得结合上下文和动作引导：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 说明具体价值，比如：
"laravel/octane": "启用 Swoole 或 RoadRunner 提升响应速度（需额外配置）" - 避免模糊表述，删掉“可选”“推荐”这类弱动词，改用“需要 X 才能启用 Y 功能”
- 若建议包有安装后步骤（如发布配置、注册服务提供者），务必在字符串里带简短指令，例如：
"spatie/laravel-permission": "运行 php artisan vendor:publish --provider="Spatie\Permission\PermissionServiceProvider"" - 不建议跨生态乱推，比如在 Symfony 包里强推 Laravel 专属包，容易引发困惑
如何让 suggests 变成实际安装引导
靠纯 JSON 字段做不到自动安装，但可以组合以下方式增强落地效果：
- 在
post-install-cmd和post-update-cmd脚本里读取composer show --all --format=json输出，筛选出当前包的suggests，再用echo或printf重新格式化输出，加粗或换行突出显示 - 在包的
README.md顶部显眼位置复述suggests内容，并附带一键安装命令：composer require spatie/laravel-permission
- 提供
bin/install-suggested脚本（需设为可执行），用 PHP 解析自身composer.json的suggests，列出选项供用户交互选择是否安装 - 若用 Composer 2.5+，可配合插件机制（如
composer-plugin-api）监听Event::POST_INSTALL_CMD，动态注入提示，但开发成本明显上升
常见误用和静默失效场景
很多开发者以为写了 suggests 就等于“做了推荐”，结果用户照常跳过——问题往往出在这些细节：
- 项目启用了
COMPOSER_NO_INTERACTION=1或 CI 环境默认 quiet，suggests根本不输出 - 用户用
composer require foo/bar -n（非交互模式），提示被吞掉 -
suggests里写的包名拼错，或版本约束写成"^2.0 || ^3.0"却没注明兼容性，导致用户手动装时失败 - 把本应是
require-dev的工具类包（如phpunit/phpunit）塞进suggests，混淆使用意图
真正起作用的从来不是字段本身，而是你有没有在用户执行命令的「那个瞬间」，把建议变成一句他愿意停下来读、并顺手敲下 composer require 的话。
