suggest仅作安装后提示，不触发安装或加载；provide声明虚拟包实现，需配合正确autoload；条件依赖须运行时检测，Composer无动态装包能力。
composer.json 里 suggest 不会安装包，只是提示
很多人误以为 suggest 是“可选依赖”，加了就能按需装——其实它纯属文档性质，Composer 安装时完全忽略它，连检查都懒得做。suggest 的唯一作用是 在 composer install 或 composer update 结束后，把那几行文字打印出来给开发者看，比如 “你装了这个库，但没装 monolog/monolog，建议装上以便启用日志功能”。
常见错误现象：
– 明明写了 "suggest": {"monolog/monolog": "用于记录调试日志"}，结果运行时抛出 Class 'MonologLogger' not found
– 以为加了 suggest 就能自动触发条件加载逻辑
-
suggest里的包名和描述不参与任何自动判断、不修改 autoloader、不影响class_exists() - 如果你的代码实际依赖某个类存在，必须确保该类已加载；
suggest不提供任何运行时保障 - 适合用在“增强体验但非必需”的场景，比如 IDE 支持、额外驱动、可视化调试工具
provide 是声明“我实现了某接口或虚拟包”，不是声明“我能替代谁”
provide 常被当成“兼容替换声明”，比如写 "provide": {"psr/log-implementation": "1.0"}，意思是“我这个包自己提供了 PSR-3 日志实现”，而不是“我能让别人不装 monolog”。它的核心用途是 让其他包通过 require 虚拟包名来表达抽象依赖。
使用场景：
– 框架 A 要求用户必须提供一个 psr/log-implementation，但它不指定具体哪家日志库
– 你的轻量日志包声明了 "provide": {"psr/log-implementation": "2.0"}，用户装了它，框架 A 的 require 就算满足
-
provide只在依赖解析阶段起作用，Composer 用它判断“是否满足某虚拟包要求”，不触发安装、不修改行为 - 不能靠它做运行时分支：比如不能写“如果提供了 X，就调 X 的方法”，得自己用
class_exists()或interface_exists()判断 - 版本号填的是你“声称实现的规范版本”，不是你自己包的版本；填错会导致依赖解析失败（如填
"1.0"却只实现了LoggerInterface::log()的新签名）
真有条件性依赖？得靠运行时检测 + 手动 require
Composer 本身没有“根据 PHP 版本/扩展/环境变量动态装包”的能力。所谓“条件性”，只能拆成两层：安装时靠 require-dev 或脚本手动干预，运行时靠代码检测 + 自动加载控制。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
比如你想“有 ext-redis 就用 Redis 缓存，否则回退到 FileCache”：
- 不要指望 Composer 自动装
phpredis—— 它不在require里就不会进 vendor - 必须把
phpredis写进require（强依赖），或放进require-dev（仅开发用），再靠 CI/部署脚本决定是否安装 - 运行时用
extension_loaded('redis')判断，再决定 new 哪个类；类名要能被 autoloader 找到（即对应包已安装） - 若想支持“按需安装”，得让用户自己执行
composer require phpredis/phpredis，你的包只负责兼容
性能影响：频繁 class_exists() 没问题，但别在热路径反复 require_once 文件；推荐把探测逻辑提到初始化阶段缓存结果。
容易被忽略的坑：autoload + provide 组合失效
最隐蔽的问题是：你写了 provide，也写了 autoload，但用户装了你的包，却 still get Class not found。
原因往往只有一个：autoload 规则没覆盖到你声称提供的那个接口/类所在的文件。比如你声明 "provide": {"psr/http-message-implementation": "2.0"}，但 autoload["psr-4"] 指向的是 "My\Http\": "src/"，而实际接口定义在 vendor/psr/http-message/src/MessageInterface.php —— 这个文件根本不是你提供的，Composer 也不会帮你代理加载。
-
provide不等于“我把这个文件打包进来了”，它只是口头承诺；你得确保对应类真的存在且可 autoload - 虚拟包（如
psr/log-implementation）没有真实源码，所以你必须自己实现并正确 autoload - 检查方式：装完包后运行
composer dump-autoload -o，再用composer show --platform看是否识别到你提供的虚拟包
复杂点在于，provide 和 autoload 是两条线：一条告诉 Composer “我能满足什么需求”，另一条告诉它 “我的代码在哪”。漏掉任何一环，下游依赖就断了。
