project-root/
├─ thinkphp/
├─ app/
├─ config/
├─ public/
│ └─ index.php ← 原始 FPM 入口文件
├─ server.php ← Workerman 启动器(新增的)
└─ composer.json
在你现有的项目目录下,Composer安装:
composer require workerman/workerman
有些composer代理镜像不全,使用以上命令composer config -g --unset repos.packagist 移除代理,再安装
php server.php start
php server.php start --debug
php server.php stop
php server.php restart
| 项目 | 推荐值 |
|---|---|
$worker->count |
CPU核心数(建议=4或更多) |
内存阈值 $limitMB |
256~512 MB 之间 |
| Cache-Control | max-age=3600 可按需求调整 |
| 守护模式 | php server.php start -d |
| 日志 | 建议使用 Workerman 自带日志 /workerman.log |
| 特性 | 说明 |
|---|---|
| 🚀 常驻内存 | 框架核心只初始化一次,性能可提升 5~10 倍 |
| ♻️ 热更新 | 文件改动自动重启 Worker,免手动 |
| 🧠 内存监控 | 超出限制自动重启进程 |
| 💡 兼容性 | 完全兼容 ThinkPHP 原有代码,不需改任何控制器 |
| ⚙️ 灵活 | 可挂载多应用、API、后台等不同 Worker |
| 模块 | 功能 |
|---|---|
build_server() |
把 Workerman 的请求头映射到 PHP 超全局 $_SERVER |
App()->http->run() |
调用 ThinkPHP 的原生 HTTP 内核,执行路由匹配、控制器调用、返回响应 |
Response |
直接使用 ThinkPHP 返回对象的内容、状态码、头部 |
http->end() |
释放上下文(防止请求间内存污染) |
[2025-10-25 18:21:12] GET / 2.14ms
[2025-10-25 18:21:15] GET /public/js/app.js 0.73ms
[2025-10-25 18:21:19] POST /api/user/login 3.81ms
生产环境上了吗
跟那个环境没有关系吧,只要能符合工作机制的框架都可以使用workerman作为启动器来加壳,将其它框架请求响应转换成workerman的请求和响应
直接webman吧 多省心
Thinkphp 的用户群体还是相当的大,很多历史项目,没办法完全重构。
容易有内存泄漏,很危险不建议这么搞
我已经测试出内存溢出的问题。O(∩_∩)O哈哈~
关于内存溢出的问题:
由于TP框架是为FPM/短生命周期模型设计,而Workerman 是常驻内存,长生命周期模型,每次请求后,tp的框架示例app,静态类,Facade单例,Event,Cache,容器,全局变量,session变量,Logger等都不会自动释放,慢慢堆积后导致内存溢出的 现在折中办法是对超过内存阈值的时候,自动重载服务,对linux测试,重载几乎无感,顶多刷新一次,但对windows可能会导致进程直接死掉退出。这有待研究吧。
你这个方案我曾经试过,可以的。当初tp官方是内置了workerman的,直接composer安装官方的就行了。但是他们也有内存溢出的情况