suggests 是纯提示性字段，不触发自动安装或依赖解析，仅作为文档提示用户可选依赖或扩展，Composer 完全忽略它，不会校验、下载或报错。

composer.json 中的 suggests 是纯提示性字段，不触发任何自动安装或依赖解析

suggests 本质是一组键值对，用来告诉使用者：“如果你用到了本包的某些功能，可能还需要这些额外的包”。它完全不影响 composer install 或 composer update 的行为——Composer 不会下载、不校验版本、不检查是否已安装，甚至连警告都不会抛。

典型场景是可选扩展支持：比如一个日志库建议搭配 monolog/monolog 使用，但本身不依赖它；又或者一个数据库抽象层建议 ext-pdo_mysql 扩展，只是提醒运行时需要。

• 键是包名或 PHP 扩展名（如 "monolog/monolog": "For advanced logging handlers"）
• 值是字符串说明，仅用于显示，无结构要求
• 不会出现在 composer show 的依赖树里，只在 composer info vendor/package 输出末尾显示

为什么 suggests 不会解决“类未找到”这类运行时错误

很多人误以为加了 suggests 就能“让 Composer 帮忙装上”，结果在代码里用了 Monolog\Logger 却报 Class not found。这是因为 suggests 和自动加载、依赖注入、条件加载都无关——它只是文档的一部分，藏在 composer.json 里，连 Composer 自己都不拿它做任何逻辑判断。

• 要真正启用某项功能，必须手动 composer require monolog/monolog
• 如果包内做了运行时检测（如 class_exists('Monolog\Logger')），那它自己负责分支逻辑，suggests 不参与
• PHP 扩展建议（如 "ext-redis": "To use Redis cache driver"）更需人工确认是否已启用，Composer 不会调用 extension_loaded()

如何让 suggests 对用户真正有用

关键不是写得多，而是写得准、写得及时。用户看到提示时，应该能立刻判断“我现在是不是需要这个”。很多包把一堆冷门扩展全列进去，反而降低可信度。

• 只列当前包**实际检测并适配过**的扩展或包，不要堆砌“理论上可以配合”
• 说明要具体，避免模糊表述。差：“For better performance”；好：“For async log shipping via AMQP (requires ext-amqp >=1.10)”
• 如果某个建议包有多个版本兼容差异，可在说明中点明，例如：“v2.x required for PSR-18 support”

{
    "suggests": {
        "php-http/guzzle7-adapter": "To use Guzzle 7 as HTTP client for API calls",
        "ext-xml": "To parse XML responses from legacy endpoints"
    }
}

和 require-dev、conflict、provide 的根本区别在哪

suggests 是唯一没有约束力的元信息字段。其他几个都会被 Composer 强制执行：

• require-dev：只在开发环境安装，但仍是硬依赖，缺失会导致 composer install --no-dev 失败
• conflict：直接阻止安装冲突版本，Composer 会报错退出
• provide：声明本包实现了某个虚拟包（如 psr/log-implementation），影响其他包的依赖解析
• suggests：输出完就结束，连日志级别都算不上，属于“你爱看不看”的范畴

所以别指望靠 suggests 实现功能兜底或环境检查——它只是个便利贴，贴在哪、写什么，全靠维护者自觉。用户真要靠它来搭环境，八成会漏掉关键依赖。