介紹
happy-join-hyperf
本計劃由 Hyperf 使用者自行發起並加入，主要為了解決從其他 PHP框架 轉到 Hyperf框架 開發時，核心元件無法被代替，導致需要重寫大量程式碼的問題。
需要嗨化的元件，可以使用以下命令加入此計劃
composer require limingxinleo/happy-join-hyperf --dev當我們將倉庫 push 到 Github 之後，就可以被自動識別，如下圖所示
第一個嗨化的元件
這裡介紹第一個被 Hyperf 化的元件
前不久，群裡有小夥伴希望可以為 hyperf/cache 增加 tags 功能，當我第一次聽到 tags 的時候，完全是懵逼狀態，
這是個什麼東西？
後來發現，這是 Laravel 的一個特性，如果沒有使用過的人，完全不知道這個特性的功能。但對於大量使用此功能的 Laravel 開發者，遷移專案的時候，這個特性可能就顯得額外重要了。
所以，就有了這個可以直接使用 illuminate/cache 的需求。而移植元件，對普通開發者而言，或者對於不熟悉 Hyperf 的開發者而言，確實有些困難。
於是，我便花了一上午的時間，將此元件做了移植，並進行開源。
嗨化規則
我希望所有嗨化的元件可以儘量遵守以下規則：
- 保留原元件的
LICENSE - 儘量保留原元件名稱空間
- 依賴
happy-join-hyperf元件，方便Github識別 READMD.md中寫明白與原元件的區別- 保持一個可以持續開源的心態，為自己的元件負責，嚴禁當
甩手掌櫃
關於 Hyperf
Hyperf 是基於 Swoole 4.5+ 實現的高效能、高靈活性的 PHP 協程框架，內建協程伺服器及大量常用的元件，效能較傳統基於 PHP-FPM 的框架有質的提升，提供超高效能的同時，也保持著極其靈活的可擴充套件性，標準元件均基於 PSR 標準 實現，基於強大的依賴注入設計，保證了絕大部分元件或類都是 可替換 與 可複用 的。
框架元件庫除了常見的協程版的 MySQL 客戶端、Redis 客戶端，還為您準備了協程版的 Eloquent ORM、WebSocket 服務端及客戶端、JSON RPC 服務端及客戶端、GRPC 服務端及客戶端、OpenTracing(Zipkin, Jaeger) 客戶端、Guzzle HTTP 客戶端、Elasticsearch 客戶端、Consul、Nacos 服務中心、ETCD 客戶端、AMQP 元件、Nats 元件、Apollo、ETCD、Zookeeper、Nacos 和阿里雲 ACM 的配置中心、基於令牌桶演算法的限流器、通用連線池、熔斷器、Swagger 文件生成、Swoole Tracker、Blade、Smarty、Twig、Plates 和 ThinkTemplate 檢視引擎、Snowflake 全域性ID生成器、Prometheus 服務監控 等元件，省去了自己實現對應協程版本的麻煩。
Hyperf 還提供了 基於 PSR-11 的依賴注入容器、註解、AOP 面向切面程式設計、基於 PSR-15 的中介軟體、自定義程式、基於 PSR-14 的事件管理器、Redis/RabbitMQ 訊息佇列、自動模型快取、基於 PSR-16 的快取、Crontab 秒級定時任務、Session、i18n 國際化、Validation 表單驗證 等非常便捷的功能，滿足豐富的技術場景和業務場景，開箱即用。
本作品採用《CC 協議》，轉載必須註明作者和本文連結