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可提升类加载速度，尤其在大量服务类场景下效果明显
