PHP扛住30万连接，10MB内存到底怎么省出来的？真相有点反常识。
上个月帮公司搞WebSocket网关，测试环境跑着跑着，top一看：PHP进程只占9.7MB，却挂着298431个在线连接。我盯着屏幕愣了两分钟——这不对劲，按以前PHP-FPM每请求开几MB的习惯，早该炸了。
不是PHP突然变强了，是它不按老规矩跑了。以前PHP开一个请求，就得从头加载框架、连数据库、初始化对象，完事扔掉重来。现在Swoole把它按住，让整个服务一直蹲着不退出。30万个连接不是30万个PHP进程，是30万个轻量协程，每个只占4KB栈空间，全加起来才120MB左右。可实际内存才10MB，因为大部分协程在等消息，栈根本没用满，系统偷偷复用内存。
关键不是“省”，是“绕开”。比如存用户ID和连接号映射，没用Redis，用了Swoole自带的Table。它直接映射一块共享内存，不走网络、不序列化、不加锁，写进去马上所有Worker都能读。我算过一笔账：512×1024个槽位，每个存两个int，对齐后一共就3.8MB，还能多个进程一起用，不重复存。
Socket缓冲区也动了刀。默认内核给每个连接分2MB缓冲，30万连就是60GB——这谁受得了？我们调成128KB，不是瞎猜：心跳包64字节，普通消息大多在2KB以内，大文件走独立上传接口。测了三天，缓冲区利用率稳定在91%上下，没丢包也没溢出。
连接管理也做减法。握手时客户端报个uid，服务端只记fd→uid这一对，别的啥也不存。不保存用户权限、不缓存头像、不记上次发了啥。状态全甩给前端或后端微服务。超时检查也不靠客户端心跳，server->tick()每秒扫一遍Table，time字段比当前小300秒的，直接踢。
Linux配置也动了。ulimit -n 调到100万，不然连5万都卡住；net.core.somaxconn 改成65535，不然新连接会排队堵死；vm.swappiness=1，基本不让内存换到硬盘——换一次IO，延迟就飘了。
worker_num 没设成CPU核数的两倍，只设了4。试过8个，CPU占用反而涨了20%，调度更乱。max_connection 设成50万，不是为了硬撑，是告诉系统：“你提前把连接池资源备好”，配合ulimit才真正生效。
监控不是装饰。server->stats()每10秒推一次连接数和协程数，Grafana画线；on('message')里插一句memory_get_usage()，发现某次闭包里use了大数组没unset，内存爬升得飞快，删掉立马压下去。
有人问，这方案能干啥不能干啥？CPU密集型任务别往里塞，比如视频转码，协程再快也跑不赢单核。真要算，得甩给task_worker进程。还有强事务场景，比如扣款，协程切走一瞬间，数据库事务可能就断了，得用Swoole自带的协程MySQL驱动，手动控制commit时机。
代码里所有sleep都换成co::sleep，所有file_get_contents换成协程版HTTP client，所有PDO操作前确认是不是协程安全的驱动。这不是矫情，是实测结果：一个阻塞函数就能让几千个连接卡顿。
广播用swoole_server->push()，点对点就查Table找fd，然后push。没用任何中间件，没走MQ，没加一层代理。消息一来，找到fd，发完就完，不记录、不回执、不补发。靠前端重连兜底，简单粗暴。
有人觉得PHP土，可土有土的好处：语法熟、人多、框架全、排错快。Swoole没改PHP语法，只换了它的“心脏”——从临时工变成常驻保安，从搬砖模式变成流水线作业。
