Webman是基于Workerman的高性能HTTP服务框架，适合高并发API、HTTP+WebSocket混合场景及复用Laravel/ThinkPHP组件的同步阻塞型项目。
Webman 不是微服务框架，它本身不提供服务发现、注册、熔断、配置中心等微服务基础设施；想用它做微服务，得自己补或集成第三方组件。
Webman 适合什么场景
Webman 是一个基于 Workerman 的高性能 HTTP 服务框架，核心价值在「常驻内存 + 同步阻塞模型下的高吞吐」。它适合：
- 需要替代 PHP-FPM 的高并发 API 服务（如订单中心、用户中心）
- 已有 Laravel/ThinkPHP 组件想复用，又不愿重写异步逻辑的项目
- HTTP + WebSocket 混合协议场景（比如实时库存看板）
- 团队熟悉传统 MVC 开发，但希望提升性能，又不想立刻切换协程心智模型
它的路由、中间件、控制器写法和 Laravel 高度相似，config/app.php、app/controller 这些路径结构也一致——迁移成本低，但本质仍是同步阻塞模型，file_get_contents 或 mysqli_query 这类阻塞调用会卡住整个进程。
Hyperf 的微服务能力从哪来
Hyperf 的微服务能力不是“可选插件”，而是设计在骨架里的：
立即学习“PHP免费学习笔记（深入）”；
-
hyperf/service-governance提供服务注册与发现（支持 Nacos/Etcd/Consul） -
hyperf/circuit-breaker内置熔断器，可按方法粒度配置失败阈值和休眠时间 -
hyperf/config-center支持动态配置拉取，配合 Apollo/Nacos 实现运行时生效 - 所有客户端（
Hyperf\Redis\Redis、Hyperf\Contract\ConnectionInterface）默认协程安全，无需手动go()就能并发调用
但代价也很实在：启动慢（依赖注入容器初始化开销大）、内存占用高（每个协程栈默认 2MB）、调试困难（协程上下文切换导致 var_dump 不稳定）。如果你的业务没有跨服务调用、无状态、不需灰度发布，Hyperf 的这些能力就是冗余负担。
Workerman 和 Webman 的关系别搞混
Workerman 是底层网络框架，Webman 是它的上层封装。它们的关系不是“竞争”，而是“父子”：
- 你直接用
workerman/workerman，就得手写事件循环、连接管理、协议解析——适合做 IM 网关、设备接入层 - 你用
workerman/webman-framework，就自动获得 HTTP 路由、中间件、静态资源处理等能力，但底层仍是多进程模型，不带协程 - Webman 的
composer.json里明确依赖"workerman/workerman": "^4.0.4 || ^5.0.0"，升级 Webman 前必须确认 Workerman 版本兼容性
常见误区是以为“Webman 支持协程”，其实它只在 v1.6+ 后通过 ext-fiber 或 swoole 扩展提供可选协程调度，但默认关闭，且控制器逻辑仍按同步方式执行。
选型时最容易被忽略的点
真正决定选 Webman 还是 Hyperf 的，往往不是 QPS 数字，而是团队对“阻塞 vs 协程”的容忍边界：
- 如果数据库查询平均耗时 > 200ms，Webman 的 Worker 进程容易被占满，出现请求堆积，此时加进程数不如换协程
- Hyperf 的
@Inject注解和 DI 容器在大型模块化项目中确实提升可维护性，但一旦遇到ReflectionException或Container is not initialized，排查路径比 Webman 的new UserController()直接实例化长得多 - Webman 的日志默认走
Monolog，Hyperf 默认用Hyperf\Logger\LoggerFactory，两者在 Swoole 子进程 fork 后的行为不同：Monolog 可能丢失部分日志，而 Hyperf 的 logger 会自动重连文件句柄
没有银弹。Webman 的轻量和确定性，恰恰来自它不做微服务；Hyperf 的企业级能力，也恰恰来自它必须承担更多抽象成本。
