workerman主动推送需严控配置：协议须匹配（如websocket://）、监听地址用0.0.0.0但须配防火墙、端口避开1–1023；count值勿超cpu核数2倍；uid映射必须用双层结构+自动清空空组；心跳设ping_interval=25与ping_not_response_limit=2以适配nat；wss证书路径须绝对且有读权。
Workerman主动推送信息时，配置文件里几个关键参数稍不注意就会导致服务启动失败、连接断开或内存暴涨，尤其在ThinkPHP8等框架集成场景下，错误配置会直接让实时通知功能失效。
监听地址和端口配置
第一步：确认协议类型与监听地址是否匹配。WebSocket服务必须用websocket://前缀，HTTP服务用http://，TCP用tcp://——写错协议会导致Worker根本无法绑定端口。
第二步：检查IP绑定范围。若写成websocket://127.0.0.1:2346，外部客户端将无法连接；生产环境务必用websocket://0.0.0.0:2346，但【不能在公网服务器上开放0.0.0.0且不设防火墙】，否则存在未授权访问风险。
第三步：端口号避开系统保留端口（1–1023）和常用服务端口（如80、443、3306），推荐使用2000以上非冲突端口，例如2121、2346、9502。
进程数（count）设置
方法一：直接写死数值$worker->count = 4;
这适合CPU核心数明确的服务器，但【count值超过CPU核心数2倍后，并发性能反而下降】，还会加剧内存占用。
方法二：动态适配$worker->count = intval(sysconf('cpu_count', 4)) ?: 4;
从系统读取真实CPU核数更稳妥，避免在Docker容器中误读宿主机核数。
UID绑定与连接映射清理
这是最隐蔽也最致命的坑。很多开发者只在onClose里简单unset($ws_worker->uidConnections[$connection->uid])，却忽略了Connection对象本身仍被其他变量引用，PHP GC无法回收。
正确做法是使用双层映射管理类，在onClose中调用ConnectionManager::getInstance()->remove($uid, $connection->id)，并确保该类实现自动清空空uid组逻辑。
若跳过这一步，服务运行4小时后内存可能增长1.2GB以上，订单推送延迟飙升至10秒+。
心跳超时与检测间隔
GatewayWorker中'ping_interval'和'ping_not_response_limit'必须成对调整：
• 'ping_interval' => 25 表示每25秒发一次ping帧
• 'ping_not_response_limit' => 2 表示连续2次没收到pong就断开连接
这样实际容忍断连时间为50秒，刚好绕过多数NAT网关60秒超时阈值。
若把ping_interval设为60，而ping_not_response_limit仍为2，客户端因网络抖动丢一个包就会被误踢，用户频繁重连。
SSL证书路径配置
启用WSS时，'ssl' => ['local_cert' => '/path/to/cert.pem', 'local_pk' => '/path/to/key.pem']中的路径必须是绝对路径，且PHP进程要有读取权限。
相对路径（如./cert.pem）在CLI模式下会以当前执行目录为基准，但守护进程启动时工作目录可能是/，导致证书加载失败，WebSocket握手直接返回500错误。
