去年接了一个运营中台的项目初期一切正常直到客户提了一个需求订单状态一变更客服工作台必须在1秒内收到通知同时运营大屏要实时刷新。我们第一版用轮询被产品经理和运维同时吐槽接口QPS高得离谱数据库连接数一路爬坡半夜都能收到告警。后来我翻了ThinkPHP8可以搭配的常驻服务方案看到官方一直维护的Workerman桥接组件才决定把常驻进程引入项目用长连接而不是短轮询来扛住实时性。这篇文章就是我这次整合的完整复盘。我会把ThinkPHP8和Workerman结合的全过程拆开讲包括为什么这么搭、环境怎么准备、请求如何从Workerman落到ThinkPHP的路由和控制器、WebSocket实时通知怎么实现以及后面在生产环境踩到的一堆坑。如果你项目里已经用了ThinkPHP8正打算加实时推送、异步任务或者长连接服务这篇文章很适合你如果你只是听过Workerman想知道它跟ThinkPHP能不能配合也可以跟着走一遍。1. 为什么要在ThinkPHP8项目里塞一个常驻服务1.1 PHP传统生命周期的天花板传统的PHP-FPM模式有一个根深蒂固的特点请求进来进程执行完脚本所有资源立刻销毁下一个请求重新从零开始。这个设计让PHP的进程模型非常简单内存安全、进程隔离都天然成立但代价就是同一个应用代码被反复加载、反复初始化。ThinkPHP8在这套模型下表现得很稳定一个请求从public/index.php进入加载Composer依赖初始化应用容器解析路由走中间件调用控制器最后输出响应。整个过程在FPM模式下重复一万次也不会有问题因为每次请求都是一次干净的新生。但是当需求变成服务端主动推消息给客户端的时候这套模型就暴露了根本性问题。WebSocket连接需要保持存活一个连接的生命周期可能持续几分钟甚至几小时期间服务端要随时往这个连接上写数据。在FPM模式下请求处理完进程就退出了连接谁来维持数据谁来发送这就是为什么PHP生态里必须有一个能常驻内存的进程框架来补位。1.2 Workerman到底改变了什么Workerman是纯PHP实现的事件驱动框架它让PHP进程启动后不退出而是进入一个事件循环。连接来了触发连接回调消息来了触发消息回调处理完继续等待不会销毁整条进程。它模拟了一套类似Node.js的事件机制但保留了你熟悉的PHP语法和Composer生态。我用一个类比来理解这件事FPM像一个自助餐厅每来一批客人就临时搭建一条生产线客人吃完生产线就拆掉下一批再重搭Workerman像一个流水线车间设备常开工人就在工位边上等着一批原料上来走一批工位干完活继续等下一批。前者灵活但浪费严重后者高效但需要更精细地维护设备状态。Workerman项目里还有两个生态组件Workerman主库负责底层的连接管理和事件循环GatewayWorker则是专门为长连接应用封装的网关框架提供客户端连接管理、分布式部署能力。不过在我们跟ThinkPHP8整合的场景里很多时候直接用官方桥接组件topthink/think-worker就够了它会处理好连接和框架请求内核之间的转换。1.3 什么样的业务真正需要它不是所有项目都需要引入常驻进程引入就代表着运维复杂度上升。我判断的标准有三个满足任何一个都值得做第一需要服务端主动推送数据。比如订单状态实时通知、站内信弹窗、运营大屏刷新、聊天室消息。这种场景用HTTP轮询既浪费资源又做不到真正的毫秒级必须上WebSocket。第二有比较重的异步任务。比如批量发送短信、生成报表、RPA任务调用一个HTTP请求同步跑完可能十几秒用户早走了。把这些任务丢进常驻进程里排队执行接口只返回已受理体验完全不同。第三大量短请求需要降低重复初始化开销。比如内部网关、统一鉴权服务请求量非常大且每个请求逻辑并不复杂如果每个请求都重新加载框架系统开销不小。常驻进程可以省掉这部分重复工作。我当时三个条件占了前两个所以下定决心在ThinkPHP8项目里整合Workerman。2. 动手前先规划环境、版本与依赖选择2.1 环境检查清单整合之前先检查运行环境。Workerman对PHP版本有明确要求而ThinkPHP8本身也要求PHP 8.0以上。我建议直接上PHP 8.1或8.2原因很简单ThinkPHP8使用了一些新语法特性老版本PHP虽然能跑但会碰到兼容性警告PHP 8.2以上对动态属性有更严格的限制老扩展容易触发警告。我整理了一张检查清单照着过一遍就行检查项推荐值/要求说明PHP版本8.1或8.28.0能跑但建议升级8.2最稳pcntl扩展必须进程控制、信号处理依赖它posix扩展必须进程用户组操作依赖它event扩展强烈建议事件驱动扩展提升并发处理性能Windows环境不推荐生产可以开发调试生产一定用Linux怎么快速检查扩展是否存在命令行执行php -m | grep -E pcntl|posix|event如果缺失pcntl和posix在CentOS或Ubuntu上通常可以直接安装对应的PHP扩展包。macOS上使用Homebrew安装的PHP默认可能没带需要额外brew install php-pcntl或者重装PHP时加扩展。这里有个很容易忽略的点event扩展是可选的但装上之后Workerman的性能会有明显提升因为底层会用libevent的事件循环机制而不是PHP自带的select。如果服务器上能装尽量装。2.2 安装think-worker组件ThinkPHP官方在框架之外维护了一个组件包topthink/think-worker目的就是做Workerman和ThinkPHP之间的桥接。在项目根目录执行composer require topthink/think-worker安装完成之后config目录下会生成一个workerman.php配置文件。第一次跑的时候建议把配置调成适合本机测试的状态?php // config/workerman.php return [ host 0.0.0.0, port 2346, process_count 2, daemonize false, pid_file runtime_path() . worker.pid, log_file runtime_path() . worker.log, stdout_file runtime_path() . stdout.log, ];process_count一开始设成2就够了方便观察日志后面调优再根据CPU核数调整。daemonize设成false这样直接在前台跑能看到所有日志方便排查问题。调试阶段千万别急着守护进程化。安装完成后运行php think worker -h能输出命令帮助信息说明桥接组件已经就位。这一步会同时拉入workerman/workerman依赖所以不需要单独装Workerman。2.3 提前规划模块和路由有一件事需要提前想清楚Worker服务启动后它监听的端口收到的请求会交给ThinkPHP自己的路由解析。也就是说你的多模块、多级目录路由访问规则在Worker模式下依然有效。我在实际项目里的目录结构大概是这样app/ ├── common/ ├── admin/ │ └── controller/ │ ├── Order.php │ └── Dashboard.php └── api/ └── controller/ ├── Message.php └── User.php原先通过浏览器访问/admin/order/detail/id/1在Worker服务下同样有效。因为think-worker收到HTTP请求后会把URL路径作为pathinfo交给ThinkPHP的HTTP内核去解析。很多朋友第一次接触这个整合以为上了Workerman就得把路由全部重写一遍其实完全不用。不过要注意一个细节你在ThinkPHP8里配置了多级目录的控制器路径比如admin模块下的二级子目录controller/group那么在访问时URL要写成/admin/group/action/...。在Worker模式下也一样规则没有变化。这也意味着你本来写好的后台模块、API模块的控制器和中间件几乎零改动就能继续在Worker服务里使用。3. 整合的关键路径从启动命令到请求落地3.1 启动Worker服务环境准备好了直接启动服务php think worker默认监听的是前面配置的2346端口。打开浏览器访问http://127.0.0.1:2346/如果配置正确你会看到和FPM模式一样的响应内容可能是首页路由的输出也可能是默认的路由错误页。这一步实际上已经说明ThinkPHP的请求内核在Workerman进程里跑通了。停服务和重启服务分别用php think worker -g stop php think worker -g restart需要提醒的是不同版本的think-worker对命令行参数的支持不太一样。有的版本用-g表示全局操作有的版本可能没有这个参数。最靠谱的方法是安装完后先运行php think worker -h看当前版本支持哪些选项以输出为准不要凭记忆硬套。3.2 理解think-worker的桥接原理整合的核心不是启动命令而是think-worker到底做了什么。它的思路很巧妙Workerman收到的数据包不是直接原样返回而是被封装成一个ThinkPHP能识别的请求对象交给ThinkPHP的HTTP内核去处理再把HTTP内核返回的响应写回Workerman连接。用伪代码表示// 伪代码think-worker 内部的核心逻辑 use think\App; use Workerman\Connection\ConnectionInterface; $worker-onMessage function (ConnectionInterface $connection, $data) use ($app) { $thinkRequest buildRequestFromWorkerData($data); $response $app-http-run($thinkRequest); $connection-send($response-getContent()); };这就解释了为什么路由、中间件、控制器、模型这些代码在Worker模式下都能原封不动地用。因为ThinkPHP的请求-响应链路一直是完整的只是这次请求的数据源从PHP-FPM的$_SERVER和php://input换成了Workerman连接收到的数据包。对应到实操层面你在控制器里用Request门面获取参数、用Db门面查询数据、用模型关联读取用户信息这些代码里没有一行需要改。3.3 常驻容器带来的串数据风险但是有一个认知必须建立起来在Worker常驻进程里ThinkPHP的容器是常驻的。FPM模式下一次请求一套容器的隔离性没有了。这意味着如果你在控制器里用静态属性或者某个存活时间特别长的单例对象去存用户级数据下一个请求很可能会读到上一个请求残留的数据。举个典型的错误写法class OrderController { private static $currentUserId; public function index() { self::$currentUserId Request::param(user_id); // 后续流程使用 self::$currentUserId } }在FPM模式下这个静态属性随请求销毁问题不大。但是在Workerman常驻进程里self::$currentUserId会一直留在进程内存中用户A的请求设置了值用户B的请求可能直接读到轻则数据错乱重则越权访问。正确的做法是请求级别的数据一律放在ThinkPHP的请求对象上也就是通过think\facade\Request去取不要用静态变量做请求级缓存。静态变量只适合保存真正的全局状态比如连接映射、配置缓存、进程级计数器。这个区分是常驻进程编程的基本功。4. 实战给运营系统加一个WebSocket实时通知中心4.1 先搭一个独立的WebSocket服务think-worker默认启动的是HTTP服务它可以处理WebSocket吗可以但我更推荐把WebSocket服务独立出来单独监听一个端口单独用一个控制台命令管理。理由很简单HTTP接口和WebSocket长连接混在一个端口里排查连接数和请求流量时很难分清。在ThinkPHP8里新建一个控制台命令php think make:command WorkerSocket然后编辑生成的app/command/WorkerSocket.php?php declare(strict_types1); namespace app\command; use think\console\Command; use think\console\Input; use think\console\Output; use Workerman\Worker; class WorkerSocket extends Command { protected function configure() { $this-setName(ws:server) -setDescription(启动WebSocket服务); } protected function execute(Input $input, Output $output) { $worker new Worker(websocket://0.0.0.0:2347); $worker-count 2; $this-registerCallbacks($worker); Worker::runAll(); return 0; } }执行php think ws:server就能启动这个WebSocket服务。这个命令走的是ThinkPHP8的控制台指令体系所以命令内部可以通过app()函数拿到容器从而使用框架的模型、服务、队列等能力。4.2 在长连接回调里调用ThinkPHP容器WebSocket服务启动后我们关注的其实是onConnect、onMessage、onClose三个回调。回调写法如下protected function registerCallbacks(Worker $worker): void { $worker-onConnect function ($connection) { echo 新连接: . $connection-getRemoteIp() . : . $connection-getRemotePort() . PHP_EOL; }; $worker-onMessage function ($connection, $data) { $app app(); // 解析消息分发到对应的业务处理类 $result $this-dispatchMessage($app, $data); $connection-send(json_encode($result)); }; $worker-onClose function ($connection) { echo 连接关闭 . PHP_EOL; }; }这里有个非常重要的经验不要想着在onWorkerStart回调里提前解析出一堆服务对象然后到处拿因为ThinkPHP的很多类都和请求生命周期绑定。在onMessage里通过app()现场获取容器实例和业务服务才能保证每次消息都能拿到上下文正确的对象。dispatchMessage可以根据消息里的cmd字段做分发protected function dispatchMessage($app, string $data): array { $payload json_decode($data, true); if (empty($payload[cmd])) { return [code 400, msg missing cmd]; } $cmd $payload[cmd]; $handler $this-getHandler($cmd); if (!$handler) { return [code 404, msg handler not found]; } // 调用对应的处理器这里可以注入容器、连接对象 return $handler-handle($payload[data] ?? []); }每个cmd对应一个处理器类比如bind_user、get_unread_count、order_subscribe。这样消息类型一多代码不会烂掉。4.3 模型多对多关联在长连接业务中的应用实时通知中心有一个很常见的鉴权需求用户连接上来先判断他是什么角色再决定要不要把某些类别的消息推送给他。这里就用到ThinkPHP8的模型多对多关联了正好也顺带记录一下TP8里多对多用法的细节。先定义User模型和Role模型?php declare(strict_types1); namespace app\model; use think\Model; class User extends Model { public function roles() { return $this-belongsToMany(Role::class, user_role, role_id, user_id); } }这里belongsToMany的参数顺序要特别留意第一个参数是目标模型第二个是中间表表名第三个是中间表指向目标模型的字段第四个是中间表指向当前模型的字段。我第一次写反了查出来的关联数据一直是反的查了很久才发现是参数顺序问题。在连接鉴权里这样用use app\model\User; $user User::with([roles])-find($userId); $roleCodes $user-roles-column(code); if (in_array(operator, $roleCodes, true) || in_array(admin, $roleCodes, true)) { // 把他加入运营通知组 $this-addToGroup($connection-id, operator); }常驻进程环境下务必用with预加载关联避免在循环里一条一条触发N1查询。因为常驻进程的数据库连接是复用的查询多了连接很容易超时而且每个查询都真实打到MySQL上性能问题会被放大很多倍。4.4 HTTP接口触发推送的完整链路WebSocket服务接收连接和消息那么后台订单状态变更怎么触发推送呢不需要WebSocket客户端再发消息只需要在原来的HTTP接口里找到目标用户的连接主动往连接上写数据。这里需要一个连接映射服务把WebSocket连接ID和业务用户ID对应起来。我用一个简单的单例类?php declare(strict_types1); namespace app\service; class ConnectionMap { private static array $map []; public static function bind($connectionId, $userId): void { self::$map[$connectionId] $userId; } public static function unbind($connectionId): void { unset(self::$map[$connectionId]); } public static function connectionIdByUser($userId) { foreach (self::$map as $cid $uid) { if ($uid $userId) { return $cid; } } return null; } }注意这里我用静态属性保存连接映射是合理的。因为连接映射本身就是进程级全局状态它需要跨请求存活这就是我前面说的真正的全局状态适合放静态变量的场景。跟把用户数据塞进静态变量是两个性质。订单状态变更的HTTP接口里这样写public function changeStatus() { $orderId Request::param(order_id); $status Request::param(status); // 更新订单状态... $cid ConnectionMap::connectionIdByUser($operatorUserId); if ($cid) { // 通过某个通道把消息交给WebSocket进程推送 // 最简单的方式是进程间通信或消息队列 } }这里有一个架构层面的难点HTTP接口运行在一个进程池里WebSocket服务运行在另一个进程池里两个进程之间怎么通信最轻量的方案是使用Workerman的Channel组件或者用一个Redis发布订阅作为中转。HTTP接口把推送事件发布到Redis频道WebSocket服务订阅这个频道收到事件后找到对应连接推送消息。如果是单体部署、简单的量级也可以用共享文件锁或者系统消息队列。但我的经验是直接引入Redis发布订阅架构清晰也用得长久。HTTP接口负责业务操作WebSocket服务负责连接和推送两者通过Redis解耦互不影响。4.5 前端连接和消息格式前端连接WebSocket的代码就用浏览器原生APIconst socket new WebSocket(ws://your-server:2347); socket.onopen () { socket.send(JSON.stringify({ cmd: bind_user, data: { user_id: 1024, token: 登录后的token } })); }; socket.onmessage (event) { const data JSON.parse(event.data); if (data.cmd order_status_changed) { // 刷新待办列表 } };这里我强烈建议从一开始就统一消息格式。格式不统一后面每加一种消息类型都痛苦。我用的格式是{ cmd: order_status_changed, data: { order_id: 10086, status: paid, notify_at: 2025-01-20 10:00:00 }, request_id: a1b2c3 }cmd表示消息类型data是业务数据request_id是链路追踪ID。有了request_id前端某个操作触发的推送出问题时可以搜日志直接定位这条命令从哪来、由哪次点击产生。5. 常驻进程的至暗时刻踩过的坑和排查思路5.1 端口占用的完整排查链路我第一次部署到测试服务器就遇到了经典的Address already in use。当时第一反应是进程没停干净于是执行ps aux | grep worker结果什么也没有。心态就有点崩了明明没有进程端口为什么被占后来一步步排查发现真正的元凶是我自己在开发机上一共启动过两个服务一个HTTP worker监听了2346一个WebSocket worker也误配成了2346两个进程互相抢占。完整的排查链路我记录下来先确认端口被谁占用netstat -tlnp | grep 2346拿到占用进程的PID再看进程信息ps -ef | grep PID如果确实是Worker进程用QUIT信号让它优雅退出kill -QUIT PID如果不是Worker进程是其他服务占用了端口那就不要强杀改配置文件的端口。这里还有一个更隐蔽的情况你改了config/workerman.php里的端口但是启动脚本会检查runtime/worker.pid是否存在旧进程没有退出的话新进程直接报端口占用。所以我的部署脚本里都会先检查pid文件存在就执行stop再启动避免这种改了配置但总感觉没生效的问题。5.2 MySQL连接中断让整个Worker遭殃这是常驻进程绕不开的问题。表现为服务跑了几个小时后进程查询数据库突然报错SQLSTATE[HY000]: General error: 2006 MySQL server has gone away。根因是MySQL服务端有一个wait_timeout参数默认8小时。连接空闲超过这个时间服务端主动断开。FPM模式下每次请求都新建立连接永远不会碰到这个问题。但Worker常驻进程里连接是复用的MySQL断开了进程不知道还拿着旧连接去查询直接就炸了。我的解决方案有两步第一步在ThinkPHP数据库配置里开启断线重连。在config/database.php的连接参数里加上break_reconnect true,这个参数的意思是检测到数据库连接异常时框架自动重连再执行查询。在常驻进程模式下这个配置一定要开。第二步在一些手动管理连接的场景下做探活。比如我在Worker里会定期执行一次轻量查询try { Db::query(SELECT 1); } catch (\Throwable $e) { Db::clear(); }执行SELECT 1的开销几乎可以忽略但能及时探测到连接失效。探测失败就调用Db::clear()让框架下次重新建立连接。这两步配合起来MySQL断线问题大幅减少。5.3 代码改了不生效和进程变僵尸刚把服务切到常驻进程时团队最不习惯的就是改了PHP代码刷新页面却完全没变化。这是因为所有类已经加载进内存了Worker进程根本不会去重新读磁盘上的文件。所以开发阶段要想办法实现热重载。Workerman本身有reload机制但需要主动给进程发信号。我用的方式是在开发机里配合一个文件监听脚本检测到.php文件变化后自动执行php think worker -g reloadreload会平滑重启业务进程不会断掉正在处理的连接适合部署更新场景。如果不想用这么复杂的机制最简单的方案是开发阶段包一层while true; do php think worker; done进程退出后马上重新拉起但那不稳定只适合临时调试。进程变僵尸的问题多半是有人手动kill了子进程但没有通知父进程。Workerman通过信号管理子进程正常停止应该用stop命令不要直接kill -9杀子进程PID。如果误杀了父进程可能会留下僵尸子进程。这时候只能整体停止再启动。还有一个常见但隐蔽的问题exit()和die()在 Worker 回调里绝不能出现。在FPM模式下你在控制器里写个exit顶多就是当前请求不输出响应PHP进程自己结束就好了。但在Workerman里exit会直接终止整个子进程这个子进程上挂着的所有连接全部瞬间断开。调试的时候一个不小心线上就是事故。我排查过最离谱的一次WebSocket服务每天固定时间点有一批连接集体断开持续了好几天。后来查日志发现是某个定时任务里的老代码写了一句exit(0)定时任务跑完就把进程干掉了挂在同一个进程下的所有长连接用户全部掉线。内存缓慢增长的问题则要持续盯。常驻进程每处理完一个请求框架会释放大部分对象但如果你在控制器里往静态数组、全局缓存里塞数据这些内存是永远释放不掉的。定时记录进程内存占用看是否有单调上升的趋势ps -C php --sort-rss -o pid,rss,cmd --no-headers如果发现某个进程RSS持续增长优先审查是不是有全局缓存或日志对象越攒越大。5.4 别忽略日志和标准输出Workerman的日志配置如果没处理好问题排查会非常痛苦。我建议把日志分成三层第一层是框架日志走ThinkPHP自带的Log记录业务日志写进runtime目录。第二层是Workerman运行日志写入config/workerman.php里配置的log_file记录连接建立、连接关闭、进程启动这些生命周期事件。第三层是标准输出日志开发环境直接看终端生产环境重定向到文件。配了stdout_file之后echo、var_dump这些调试输出都会进文件不会刷在终端上。这样即使进程在后台跑也能翻文件排查问题。日志就是常驻进程的呼吸缺了这个出了问题连从哪开始查都不知道。6. 从开发到生产进程管理、平滑重启与部署细节6.1 用Supervisor守护Worker进程生产环境不能靠人肉盯进程。我用Supervisor来守护Worker的服务进程实现两个目标进程意外退出后自动拉起服务器重启后自动恢复服务。以WebSocket服务为例在/etc/supervisor/conf.d/tp8-websocket.conf里配置[program:tp8-websocket] process_name%(program_name)s_%(process_num)02d commandphp /www/wwwroot/tp8/think ws:server autostarttrue autorestarttrue userwww numprocs1 directory/www/wwwroot/tp8 redirect_stderrtrue stdout_logfile/www/wwwroot/tp8/runtime/websocket_supervisor.log有几个细节特别重要第一user一定要和项目文件的运行用户一致否则日志目录权限经常会出问题表现为进程能起但日志写不进去。第二numprocs保持1。Supervisor只管理一个总控进程Worker内部自己会fork出多个子进程。不要把Worker配置里的count和Supervisor的numprocs混在一起两个叠起来会搞得进程数量失控。第三当用Supervisor管理时Worker配置的daemonize要设为false否则会出现双重守护的问题Supervisor已经把一个进程当儿子看着Worker再自己fork到后台Supervisor会误以为进程一直在重启。配置好之后supervisorctl update supervisorctl status看到RUNNING状态就说明守护成功。6.2 进程数、连接数和性能调优Worker进程数的设置思路跟FPM不太一样。每个Worker进程是单线程的但它基于事件循环一个进程可以同时维护大量连接。进程数的决定因素主要是CPU核心数和业务类型。我的经验如下常规业务进程数设为CPU核数。大量数据库I/O等待可以设为CPU核数的1.5到2倍。纯计算密集任务保持和CPU核数相等甚至少一点多了反而浪费上下文切换。最简单的判断方法是观察进程CPU使用率。执行top -p worker主pid如果单个子进程的CPU早就打满了就加进程数如果CPU普遍很低但响应很慢瓶颈大概率在数据库或网络加进程数没用。连接数还要受操作系统的文件描述符限制。Linux默认的ulimit -n通常是1024也就是说一个用户最多打开1024个文件描述符一个长连接至少占用一个连接一多直接报too many open files。生产环境要给运行用户调高ulimit -n 65535如果是systemd管理服务就在对应的service文件里设置LimitNOFILE65535。内存泄漏如果实在排查不到位可以给进程设置一个最大处理时长或最大请求数兜底。让子进程处理完一定数量的请求后自行退出父进程重新拉起新进程这样即使有残留的全局状态也会周期性地被清掉。Workerman这边可以通过在Worker实例上设置相关属性实现不同版本名字不一样但都有类似机制。6.3 用Nginx反代WebSocket服务器上往往不止一个应用不可能把2347端口直接对公网开放。更常见的做法是让Nginx监听80/443端口通过路径转发到Worker服务这样SSL证书、HTTP/2、访问控制都能在Nginx这一层统一处理。WebSocket反代的关键是升级连接。Nginx配置如下map $http_upgrade $connection_upgrade { default upgrade; close; } server { listen 80; server_name ws.example.com; location /ws { proxy_pass http://127.0.0.1:2347; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 3600s; } }前端连接地址就变成const socket new WebSocket(ws://ws.example.com/ws);proxy_read_timeout要设置得足够长默认60秒的话长连接一旦超过60秒没数据交互就会被Nginx切断。我之前就遇到过这个坑前端页面连上WebSocket后完全没消息过一两分钟就自动断开排查了很久才发现是Nginx的超时设置太短。6.4 上线前的安全自查最后说安全这部分在常驻进程场景里比FPM场景更容易被忽略。因为新的监听端口对外暴露了端口本身就是一个攻击面。第一host绑定要谨慎。如果业务只在内部网络使用host就写内网IP或者直接监听127.0.0.1然后通过Nginx反代不要图省事把host写成0.0.0.0后直接裸奔公网。第二WebSocket连接必须做鉴权。连接建立时前端要把token传过来服务端在bind_user这条消息里验签验签通过才把连接绑定到用户。很多实时推送的漏洞就是因为只做了能连上就信任的处理结果攻击者伪造一个连接就能收到所有推送消息。第三消息体要过验证器。不要因为WebSocket在常驻进程里就跳过框架的验证体系。我在dispatchMessage里对每个业务消息都调用了ThinkPHP8的验证器保证输入数据合法。规则和HTTP接口完全复用成本很低。第四超时连接要清理。长时间没有数据交互的连接要主动断开避免连接数被死连接占满。可以在连接对象上记录最后活跃时间写一个定时器定期扫描清理。第五日志要独立通道。生产环境的Worker服务建议单独开一个日志通道记录连接的建立、关闭、消息类型和耗时。出了问题能快速定位是哪一类连接在哪个时间段有异常。另外顺带提一下ThinkPHP8本身的部署。从官网下载最新稳定包或者直接用Composer创建项目composer create-project topthink/think tp8这个命令会拉取最新的ThinkPHP8骨架代码。版本选择上尽量用最新的稳定版我碰到过老版本在PHP 8.2下会输出关于动态属性废弃的警告升级之后就干净了。在这个项目里我最终是把HTTP Worker和WebSocket Worker分开管理的HTTP服务Nginx对接处理后台接口WebSocket服务独立端口接Nginx反代专门处理长连接。两者都通过Redis发布订阅完成业务侧的联动。这套架构上线后订单通知的推送延迟稳定在500毫秒以内运营大屏数据也是实时刷新半年多没有出过进程级故障。常驻进程带来的运维复杂度是真实存在的但只要你理解了它的生命周期、连接管理、内存清理和守护方式它就能变成项目里很可靠的一块基石。