Workerman 完全适合做 API 网关，但需自行实现认证、限流、服务发现等功能；其多进程+事件循环模型支撑5–10万并发，零编译部署便捷，但性能略逊于Swoole且不支持配置热更新。
Workerman 完全适合做 API 网关，但不是“开箱即用”的 Spring Cloud Gateway 那种——它更像一把可定制的瑞士军刀，得自己装刀片、调角度、校准力道。
为什么 Workerman 能扛住网关流量？关键看它的进程模型
Workerman 的多进程 + 事件循环模型，天然适合做反向代理类中间件：每个
进程独立处理 HTTP 连接，不共享内存，故障隔离性好；通过
/
复用连接，单机轻松支撑 5–10 万并发请求（实测数据见 2025 年基准测试）。
它不依赖 PHP-FPM，避免了 CGI 启动开销和进程复用瓶颈
HTTP Server 是纯 PHP 实现，调试时能直接用
断点进
回调，比 Swoole 协程栈追踪更直观
但注意：
进程内不能阻塞（比如同步 MySQL 查询），否则整个进程卡死，必须改用异步客户端或投递到 Task 进程
真实网关功能怎么补？别指望框架自动给你
Workerman 自带
只提供基础路由和响应，认证、限流、服务发现这些得自己搭积木：
Workerman
最新主版本，继续强化高性能异步网络能力，适合 WebSocket、HTTP 服务、长连接、IM、IoT 等场景。
本次版本主要围绕稳定性、协议兼容以及连接处理能力优化，依旧保持超轻量和纯 PHP 特性。
适用于 PHP 8.x 环境，可配合 webman、GatewayWorker 等生态使用。
下载
路由转发：用
+ 正则匹配路径，再用
或
转发到后端服务（如
）
JWT 认证：在
里解析
Header，调用自定义验证逻辑，失败直接
限流：推荐用
做分布式计数器（对接 Redis），别用内存数组——多 Worker 进程下计数不一致
服务发现：需主动集成
或
SDK，在
里注册，在转发前查实例列表并做轮询/一致性哈希
和 Swoole 比，Workerman 做网关的硬伤在哪？
性能数字上确实落后：HTTP QPS 低约 45%，WebSocket 连接数少 44%，内存占用高 50%（
vs
）。但差距背后是取舍：
Swoole 的协程调度更快，但一旦协程里用了不兼容协程的扩展（比如某些老版本
），整个请求就崩；Workerman 没这问题，所有同步扩展照常跑
Workerman 部署零编译：
后直接
，Swoole 必须装扩展，CI/CD 流水线得多维护一个 PHP 编译环节
如果你的网关要混接 PHP 旧系统（比如 Laravel 用户中心）、又得连 MQTT 设备端，Workerman 内置的
和
双协议支持反而省事
真正容易被忽略的，是配置热更新能力——Workerman 默认不支持运行时重载路由规则或限流阈值。你得自己加监听文件变更的逻辑，或者用
配合配置中心推送，否则每次改个路径就得 reload 进程，对线上服务就是抖动。
WorkerselectepollxdebugonMessageWorkerWebServer$_SERVER['REQUEST_URI']stream_socket_client()Workerman\Connection\TcpConnectionuser-service:8081onMessageAuthorization$connection->close()workerman/channelNacosConsulonWorkerStart48MB/万连接32MB/万连接pdo_mysqlcomposer require workerman/workermanphp start.php start -dMQTTHTTPworkerman/gatewayclient