Hyperf 依赖管理需严格遵循协程安全、版本对齐与框架机制要求。必须用 create-project 创建骨架,禁用 --no-scripts 会导致 DI 容器构建失败;HTTP/Redis/MySQL 等须使用官方协程适配组件;生产环境应执行 dump-autoload -o 和 install --no-dev,并配置阿里云镜像提升安装效率。

Hyperf 的依赖管理不是“随便 require 就行”,它对协程安全、版本对齐和加载机制有硬性要求。直接在已有项目里 composer require 某个 hyperf/xxx 包,大概率会出类找不到、注解失效或进程崩溃的问题。
必须用 create-project 创建骨架
Hyperf 不是普通 Composer 包,而是一套结构敏感的协程框架。不能把它当成 Laravel 的扩展包来装。
- 正确命令:
composer create-project hyperf/hyperf-skeleton my-app - 推荐锁死稳定版,比如:
composer create-project hyperf/hyperf-skeleton:3.1.25 my-app(查 GitHub Releases 获取最新 patch 版) - 执行后会自动运行
composer install,并触发HyperfDevtoolComposerScriptHandler::build脚本——生成代理类、扫描注解、构建 DI 容器,缺一不可 - 禁用
--no-scripts或--no-dev会导致 runtime/container 目录为空、@Inject失效、启动报错
添加第三方包要选协程安全版本
Hyperf 运行在 Swoole 协程中,所有 I/O 操作必须是非阻塞的。传统同步客户端会拖垮整个协程调度。
- HTTP 请求:用内置
hyperf/http-client,别require guzzlehttp/guzzle;调用方式:$this->container->get(HyperfHttpClientHttpClientFactory::class)->create() - Redis:用
hyperf/redis,它底层自动对接swoole_redis协程客户端,不是 Predis - MySQL:用
hyperf/database+hyperf/db-connection,支持连接池和协程 PDO - 其他包:优先查官方组件列表或社区验证过的协程适配版,不确定就先不加
更新与优化依赖的关键操作
日常维护不只是 composer update,还要兼顾性能、安全和环境差异。
- 生产部署前运行:
composer dump-autoload -o,启用优化自动加载,减少文件 I/O - 上线时用:
composer install --no-dev,去掉 phpunit、faker 等开发依赖,减小体积、提升安全性 - 版本约束写清楚:在
composer.json中用^3.1或~3.1.20,避免 minor 升级引入协程上下文兼容问题 - 国内安装慢?全局换镜像:
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
配置和自动加载要配合框架机制
Hyperf 的 autoload 不只是让类能被找到,还关系到注解扫描、配置合并和容器注册。
- 确保
composer.json中"autoload"和"autoload-dev"分开定义,开发类(如测试、命令)不进生产自动加载 - 组件的配置由
ConfigProvider提供,新增包后记得检查是否已注册该提供者(通常composer require会自动处理) - 若手动改过
src/下目录结构,需运行php bin/hyperf.php gen:scan重新生成注解缓存 - 启用
"optimize-autoloader": true可提升类加载速度,尤其在大量服务类场景下效果明显










