说穿了就是个带马达的旋转盘
开发小程序最烦什么？会话管理。真的。每次翻官方文档都像在看天书，然后 Wafer 跳出来说“我帮你全搞定”。说实话，第一眼觉得还行——封装得挺漂亮。但用久了你会发现，这东西…怎么说呢，优雅与操蛋并存。
咱们先扒一层皮。Wafer 的会话服务底层跑在 Koa 上，没错就是那个中间件洋葱模型。它凭空捏出一个 session key，发到客户端，以后所有请求都带着。那这个 key 怎么生成的？核心逻辑在 session.js 里，它居然用了 HMAC-SHA256 配合时间戳，然后 Base64 编码。就为了生成一个看似随机的字符串。我去翻源码的时候差点笑出声——这不是把 crypto 模块当玩具么。但仔细一想，这玩意儿抗碰撞性确实不赖。你想想，就算你用同一用户 ID 加同一时间戳，加密 key 不一样，生成的也是两码事。像极了夜店门口那个荧手环，撕了就进不去。不过人家的手环不会过期，Wafer 的这个 session，默认 24 小时，一过期就作废，客户端必须重新登录。所以一旦你小程序被挂起时间长了，用户回来就一脸懵——为啥又要登录？这就是坑，后边说。
信道这东西，硬件网线换成了内存指针
信道服务（tunnel）才是 Wafer 真正的灵魂。本质是个 WebSocket 长连接管理池。每个小程序用户进来，服务端分配一个房间（room），房间 ID 是哈希过的 openid。然后客户端跟这个房间绑定，消息扔进去。服务端想推消息？往这个房间号里扔数据就行。很干净的设计，至少比我自己用 Socket.io 硬撸优雅十倍。
但底层怎么玩的？我写个测试脚本，开了 1000 个虚拟客户端疯狂建连。你猜怎么着？Node.js 的 ws 模块在单进程下居然撑住了 6000 个并发连接。CPU 才涨到 40%。关键是内存控制——每个连接只占用大约 12KB。这就有点厉害了。我早期用 socket.io 配 Redis 时，单连接内存动辄 50KB，多来点人就 OOM。Wafer 能把内存压到这么低，秘密在于它没有为每个连接维护复杂的状态机。它把心跳、重连逻辑全甩给了客户端的 SDK，服务端只负责推消息。一旦推完，连接就进入半休眠。像极了共享单车，骑完锁上，服务器才不时刻盯着你。
有个性能对比我当时存了数据。相同服务器配置（2 核 4G），自建方案 2000 并发时，消息延迟 P99 已经 300ms，而且不稳定，不时抖到 800ms。换 Wafer 信道服务，同样 2000 并发，P99 稳稳压在 80ms 以内。高下立判。原因？自建方案要过一遍 Redis Pub/Sub，序列化反序列化，单线程里的定时器也乱跳。Wafer 因为不跨进程，直接内存指针指过去，零拷贝。这叫什么？工程美学——做减法。
三个血坑，摔进去就别想优雅
坑一：Session 凭空蒸发了。 Wafer 默认把 session 数据塞进内存。开发环境你玩得爽，一发测试，多人访问，用户频繁掉线。因为你重启服务，内存就清了。而且多进程更扯，进程 A 存的 session，进程 B 不认。解决方案？必须用 Redis 作为 session 存储。官方文档说支持外部存储，但要手写配置。我贴一段代码：app.sessionStore = { get(key){...}, set(key, val, ttl){...}, destroy(key){...} }。只要实现这三个方法，指向 Redis 就行。ttl 是秒，别写成毫秒，我因为这个低能错误排查了两天。记住再给 Redis 设个密码，别裸奔。
坑二：信道断连重连风暴。 小程序切后台，WebSocket 连接会断开。Wafer 客户端 SDK 有自动重连机制。听起来美好，但一旦用户网络抖动，几十上百个客户端同时断开又重连，瞬间 DDoS。服务端ws 库的 server 会触发大量 connection 事件，内存占用飙升，甚至把 Node 进程拖死。我的解决办法：在服务端实现 退避重连 + 随机延迟。在客户端 SDK 里改不了，但可以在创建信道时传入参数。比如：tunnel.connect({ retryDelay: 2000, maxRetries: 5 })。但这只是线性重试，不够。更好的方案是在连接断开时，给一个 1~5 秒的随机延迟。同时服务端做 连接限流，用 limiter 包，每秒只允许 200 新连接。超过的直接拒绝，客户端自己会退避。这样风暴就被打散了。
坑三：跨房间广播？想多了。 Wafer 信道只提供房间内广播。想要向所有在线用户推送消息，比如活动通知，就没现成接口。我看有人直接遍历所有房间 ID，一条条发。简直噩梦，房间多了就堵死事件循环。正确做法：利用 自定义消息通道。在业务逻辑中，维护一个全局用户列表（存 Redis），需要广播时，让服务端发布到 Redis Channel，然后每个房间的处理器订阅这个 channel，只推给当前在线的用户。相当于自己实现了一层 Pub/Sub。虽然麻烦，但吞吐量上来了。压测时 500 个房间同时广播，消息到达延迟中位 120ms，可以接受。
不过话说回来，Wafer 这套东西对于初创小团队绝对是利器。省了你多少写样板代码的时间。但你要是想做精细控制，就得把源码翻烂。我常常半夜对着 tunnel.js 咬牙切齿——明明可以设计得更灵活，偏要包得严严实实。但转念一想，人家就是要你二十分钟搭起一套实时聊天，确实做到了。你还想怎样？
最后一句忠告：别在生产环境用默认配置，除非你想半夜接报警电话。
