hyperf 不支持批量修改扩展包，但可通过组合命令高效调整：统一升级用 composer update "hyperf/*"；协程化需先 remove 阻塞包再 require 对应 hyperf 包并迁移代码；模块化扩展（如视图）应按需增删；配置中心等生态替换重在 provider 实现与配置映射。
Hyperf 中不支持“批量修改扩展包”这种操作。Composer 本身是面向单个包的声明式依赖管理工具，所有变更（安装、更新、卸载）都基于 composer.json 的明确声明，而非模糊的“批量替换”或“一键升级所有第三方扩展”。但你可以通过组合命令和配置策略，高效完成多包的协同调整——关键是理解目标：你是想统一升级？切换协程安全替代品？还是清理阻塞式旧包？下面分场景说明。
统一升级多个 Hyperf 官方组件
当项目已使用多个 hyperf/* 包（如 hyperf/redis、hyperf/http-client、hyperf/database），且希望同步升级到兼容的最新小版本（如 v3.4.x → v3.5.x），推荐方式是：
- 先运行
composer update hyperf/redis hyperf/http-client hyperf/database，只更新指定包，避免意外牵连其他依赖 - 若需全部 Hyperf 官方包升级，可用通配符：
composer update "hyperf/*"（注意引号防止 shell 解析错误） - 升级后务必检查
composer.lock中各包实际解析的版本是否符合预期，并运行测试验证协程行为（如 Redis 连接池是否复用、HTTP 调用是否仍为协程非阻塞）
将阻塞式包替换成协程安全版本
这是 Hyperf 项目中最常见也最关键的“批量调整”。不能靠“替换名字”，而要先删后装 + 代码迁移：
- 删除原阻塞包：
composer remove guzzlehttp/guzzle predis/predis illuminate/redis - 安装对应协程包：
composer require hyperf/http-client hyperf/redis - 同步修改代码：把
new GuzzleHttp\Client()改成用Hyperf\HttpClient\HttpClientFactory；把Predis\Client实例替换为 DI 注入的Hyperf\Redis\Redis - 特别注意：不要保留旧包残留。例如
illuminate/redis和hyperf/redis共存可能引发类冲突
按功能模块批量启用/禁用视图相关扩展
Hyperf v3+ 将视图拆分为分层结构，适合按需组合：
- 基础渲染能力：
composer require hyperf/view（必须） - 选择引擎实现：
composer require hyperf/blade-view或composer require hyperf/twig-view（二选一，不建议同时装） - 如需自定义引擎（如 ThinkTemplate），再额外加：
composer require sy-records/think-template，并手动注册TemplateEngine实现类 - 卸载时也应成组操作：比如停用 Blade，就
composer remove hyperf/blade-view，无需动hyperf/view
安全替换配置中心或登录等扩展生态
这类扩展通常有明确的社区约定和 Provider 机制，替换不是改包名，而是换实现：
- 例如从本地
config/autoload/切到 Consul 配置中心：composer require hashicorp/consul-php-sdk，再编写ConsulConfigProvider替代默认加载逻辑 - 第三方登录从微信扩展切到飞书：
composer remove hyperf/socialite→composer require hyperf/socialite（新版已支持飞书）→ 修改config/autoload/socialite.php中的平台配置块 - 关键点：扩展包只是“接入胶水”，真正生效的是你写的 Provider、Controller 和配置映射，包本身可更换，接口契约尽量保持稳定
