直接修改$worker->count不生效，因其仅在启动时读取；必须通过reload平滑重启（更新子进程数）或restart彻底重启主进程才能生效。
直接改 $worker->count 不生效，必须 reload 或重启主进程
Workerman 的进程数由 $worker->count 控制，但这个值只在 Worker 启动时读取一次。运行中直接修改变量（比如在 onWorkerStart 里重赋值）完全无效——子进程早已 fork 完毕，内存隔离，改了也白改。
真正可行的方式只有两种：
- 向主进程发送
reload信号：Workerman 会平滑关闭旧子进程、拉起新子进程（数量按当前代码里的$worker->count值），连接不中断，但要求代码已提前写好目标值（比如从配置文件读取） - 用进程管理器（如 Supervisor、systemd）执行
restart：更彻底，但会有短暂连接断开窗口，适合低敏感业务 - 若用 Docker/K8s，应避免手动改 count，而是通过环境变量 + 启动脚本注入，再触发滚动更新
加服务器节点 ≠ 改单机配置，关键在负载均衡层
水平扩容的本质不是“让某台机器变强”，而是“让请求能分到新机器上”。Workerman 本身不提供服务发现或自动注册能力，所有节点都是独立、无状态（或需自行管理状态）的孤岛。
所以加节点前必须确认以下三点已就绪：
- 新服务器已部署相同版本的 Workerman 应用，且监听端口、协议一致（如都监听
websocket://0.0.0.0:2346） - 前端负载均衡器（Nginx / HAProxy / 云 SLB）已将新节点 IP 加入后端服务器池，并开启健康检查（例如定期 GET
/status端点） - 客户端连接逻辑不硬编码单点地址（比如 WebSocket URL 写死
ws://old-server:2346），而应指向负载均衡 VIP 或域名
连接未优雅关闭？多半是没处理 onClose 和心跳超时
扩容后常出现“老连接卡住不释放”“新节点负载始终偏低”，根本原因不是扩容操作本身，而是连接生命周期没管好。
Workerman 默认不会主动踢掉空闲连接，必须靠你自己定义清理策略：
- 在
onConnect中设置连接超时：$connection->timeout = 60;（单位秒） - 实现心跳检测：客户端定时发 ping，服务端在
onMessage中刷新$connection->lastPingTime = time();，再配合定时器扫描并 close 超时连接 - 务必实现
onClose回调：清理用户上下文、释放资源、通知其他服务（如从 Redis 在线列表移除） - 如果用了 Redis 存连接映射，注意不同节点间无法共享内存连接对象，所有跨节点操作必须走外部存储
K8s 下扩 Pod 数量，但连接数没上去？检查 readinessProbe 和连接复用
在 Kubernetes 中执行 kubectl scale deploy/workerman --replicas=6 后，流量没立刻打到新 Pod，常见于 readinessProbe 配置不当或客户端复用连接。
典型问题和对策：
- readinessProbe 返回 200 但 Workerman 还没 ready：Probe 脚本应检查
Worker::$pidMap是否非空，或用netstat -tlnp | grep :2346确认端口已监听 - 客户端（尤其是浏览器 WebSocket）复用 TCP 连接：已有长连接不会自动切到新节点，只能等自然断连或主动重连
- Service 的 sessionAffinity 设为
ClientIP：导致同一 IP 始终打到同一 Pod，关掉它（默认是None） - 新 Pod 启动慢：检查 Dockerfile 是否把
composer install放在最后，避免镜像层缓存失效拖慢构建
