Hyperf官方组件仅限github.com/hyperf/下、包名以hyperf/开头的约20个核心与可选组件，如hyperf/http-server、hyperf/validation等；其余“70+插件”多为未经审核的社区包，稳定性与协程安全性需自行严格验证。
Hyperf 没有“官方插件市场”，所谓“70+ 插件”多为社区自发维护的第三方包，其中仅 hyperf/crontab、hyperf/async-queue、hyperf/database 等约 20 个是 Hyperf 官方维护的核心组件；其余多数未经过框架团队审核，稳定性、协程安全性、长期维护性需自行评估。
哪些组件算“官方”？认准命名空间和维护者
判断一个组件是否属于 Hyperf 官方生态，只看两点：composer require 包名是否以 hyperf/ 开头，以及 GitHub 仓库是否托管在 github.com/hyperf/ 下。例如：
-
hyperf/http-server、hyperf/validation、hyperf/redis—— 官方核心，强依赖，持续更新 -
hyperf/amqp、hyperf/kafka、hyperf/tracer—— 官方可选组件，按需安装，文档齐全 -
hyperf-skeleton、hyperf-cloud—— 非组件，是项目模板或云平台工具，不算“插件” - 任何带
hyper-hello、hyperf-ext-xxx、hyperf-plugin-xxx名称的包 —— 社区包，无官方背书
社区“插件”里真正能用的，不到一成
所谓“70+ 插件推荐”列表中，大量条目存在明显问题：
- 已归档（Archived）且近两年无 commit：如
hyperf-swagger-ui（被官方hyperf/swagger替代） - 协程不安全：直接使用
sleep()、file_get_contents()或阻塞式 PDO，会在 Hyperf 协程中挂起整个 worker - 依赖过时：要求
php: ^7.4或hyperf/framework: ^2.2，无法在当前主流的 v3.x + PHP 8.2+ 环境运行 - 文档缺失或示例失效：README 中的
use命名空间错误，或配置项名与实际类属性不一致（如把max_connections写成connection_max）
替代方案比硬塞插件更可靠
遇到功能缺失，优先考虑组合官方能力或轻量封装，而非引入未知插件：
- 需要 HTML 清洗？直接
composer require friendsofhyperf/purifier—— 这是 Friends of Hyperf 组织维护的、与 v3 兼容的稳定包，非“插件”，但比多数社区清洗类包更安全 - 要导出 Excel？
phpoffice/phpspreadsheet本身协程友好，配合hyperf/async-queue异步生成，无需找所谓“hyperf-excel 插件” - 想加请求日志脱敏？写一个
RequestLogMiddleware，用hyperf/http-message提供的ServerRequestInterface拦截并过滤敏感字段，50 行内搞定 - 定时任务要防重复？
hyperf/crontab内置mutex配置项，设"mutex": {"type": "redis"}即可，不用额外装锁包
查一个包值不值得用，三步验证法
看到推荐列表里的陌生包，别急着 composer require，先做这三件事：
- 去 GitHub 搜包名，看仓库是否在
hyperf/下；不是？跳过 - 点开
composer.json，确认"require": {"hyperf/framework": "^3.0"}是否匹配你项目版本 - 搜 Issues 和 PR，看最近三个月有没有人报
Coroutine context is lost、Segmentation fault或Undefined index: xxx类错误
协程环境里，一个未经验证的 sleep(1) 就能让整条请求链路卡死 —— 复杂点不在功能多，而在每个调用点是否真的 yield 了。
