Hyperf 通过 Composer 管理协程安全的依赖，推荐使用 hyperf/http-client、hyperf/db 等官方异步组件（1），避免同步库造成协程阻塞（2），并遵循版本约束、优化自动加载、分离开发依赖等最佳实践（3），确保高性能与稳定性。
在基于 Swoole 的 Hyperf 框架中，使用 Composer 进行依赖管理是标准且高效的做法。Hyperf 本身就是一个为协程而生的高性能 PHP 框架，底层依赖 Swoole 提供的协程能力，而所有组件和第三方库的引入都通过 Composer 统一管理。下面介绍如何正确使用 Composer 在 Hyperf 中进行依赖管理，并结合协程特性进行实践。
理解 Hyperf 与 Composer 的关系
Hyperf 遵循现代 PHP 的开发规范，完全基于 Composer 实现自动加载与依赖管理。项目初始化时通过 Composer 安装 hyperf/engine 或使用官方发行包，框架核心及所有扩展组件（如数据库、缓存、RPC 等）均以 Composer 包形式存在。
关键点：
- Hyperf 的组件拆分非常细粒度，每个功能（如 hyperf/cache、hyperf/db-connection）都是独立的 Composer 包。
- 通过 composer require 命令安装组件后，Hyperf 的注解扫描和依赖注入容器会自动识别并注册服务。
- Composer 的 autoload 机制支持 PSR-4，确保类文件能被协程环境下正确加载。
协程安全的依赖选择与安装
由于 Hyperf 运行在 Swoole 协程环境，不能随意引入传统的同步阻塞库（如普通 curl、file_get_contents）。必须选择支持协程或由 Hyperf 封装过的异步组件。
常见推荐做法：
- 使用 hyperf/http-client 替代 Guzzle（需启用协程兼容模式）或直接使用 Hyperf 封装的客户端。
- 数据库操作使用 hyperf/db，它基于 Swoole 协程 MySQL 客户端，避免传统 PDO 的阻塞问题。
- Redis 使用 hyperf/redis，内部封装了 Swoole 的协程 Redis 客户端。
- 避免引入非协程友好的扩展，例如未适配的第三方 SDK，除非确认其不造成协程污染。
依赖管理最佳实践
为了保证项目的可维护性和运行稳定性，在使用 Composer 管理 Hyperf 项目依赖时应遵循以下实践：
- 明确指定版本约束：在 composer.json 中使用 ~ 或 ^ 控制版本升级范围，避免意外更新破坏协程兼容性。
- 定期执行 composer update：结合测试流程，及时获取安全更新和性能优化，但需在预发环境验证。
- 使用 composer dump-autoload -o：生产环境部署后优化自动加载性能，减少 I/O 开销。
- 禁用 dev 依赖上线：部署时使用 composer install --no-dev 减少体积并提升安全性。
- 利用 Hyperf 命令行工具：如 php bin/hyperf.php list 查看组件状态，自动发现新安装的组件。
自定义组件与私有仓库管理
对于大型项目，可将通用逻辑封装为私有 Composer 包，便于复用。步骤如下：
- 创建独立的 Git 仓库，结构符合 PSR-4 规范，包含 composer.json。
- 在主项目中通过 repositories 添加 VCS 类型源，指向私有组件地址。
- 执行 composer require vendor/name:dev-main 引入。
- 确保组件内部不使用全局变量或静态状态，防止协程间数据共享污染。
基本上就这些。只要坚持使用官方推荐的协程组件，配合 Composer 的规范管理，就能在 Hyperf 中实现高效、稳定的服务开发。关键是选对“协程友好”的包，别让一个同步调用拖垮整个协程体系。
