用 Yamux 还是 Smux 取决于更怕内存失控还是流竞争：Yamux 适合稳定内网微服务，Smux 更适合高并发、低内存容忍的边缘或移动端场景。
直接说结论：用 yamux 还是 smux，取决于你更怕内存失控还是更怕流竞争——前者适合稳定可控的微服务内网通信，后者更适合高并发、低内存容忍度的边缘或移动端场景。
为什么不能直接用 net.Conn 做多路复用？
Go 的 net.Conn 是单连接单流模型。每个 http.Client 或自定义协议如果都新建 TCP 连接，会快速触达系统文件描述符上限（ulimit -n），且三次握手 + TIME_WAIT 消耗严重。多路复用不是“锦上添花”，而是高并发下避免连接雪崩的刚需。
常见错误现象：
- 客户端报
dial tcp: lookup xxx: no such host—— 实际是 DNS 缓存+连接风暴导致本地端口耗尽，不是 DNS 问题 - 服务端
accept阻塞或超时，但netstat -an | grep :8080 | wc -l显示连接数远低于预期 —— 真实瓶颈在应用层流建立而非 TCP 层
根本原因：TCP 连接本身不提供流隔离能力，read/write 是全局字节流，必须靠上层协议（如 Yamux/Smux）切分帧、维护流状态、做窗口控制。
立即学习“go语言免费学习笔记（深入）”；
yamux.Server() 和 smux.Server() 的初始化差异
两者 API 表面相似，但行为逻辑不同：
-
yamux.Server(conn, nil)默认启用EnableKeepAlive=true，心跳间隔 30 秒；smux.Server(conn, nil)默认关闭心跳，需手动传&smux.Config{KeepAliveInterval: 10 * time.Second} -
yamux的AcceptStream()是阻塞调用，若未设StreamOpenTimeout，客户端OpenStream()失败时服务端可能永久挂起 -
smux的AcceptStream()内部做了非阻塞轮询，配合MaxFrameSize控制单次读取上限，对突发小包更友好 -
yamux每个流独占缓冲区（默认 64KB），1000 流 ≈ 64MB；smux全局共享缓冲区（MaxStreamBuffer），1000 流仍只占一份内存
性能影响：内网延迟 yamux 吞吐略高；公网 RTT >50ms 且流数 >500 时，smux 的 TDMA 调度能更好抑制流间干扰。
流打开失败的典型原因与排查路径
无论是 session.OpenStream() 还是 session.AcceptStream() 返回 error，优先检查以下三点：
- 底层
conn是否已关闭或被远程 reset —— 查看conn.RemoteAddr().String()是否有效，抓包确认 FIN/RST 包 - 服务端
AcceptBacklog是否溢出：yamux默认 256，smux默认 128；超过后新流请求会被静默丢弃，无 error 提示 - 客户端未及时
Read导致服务端流缓冲区满 ——yamux触发窗口收缩，后续Write可能阻塞；smux则通过令牌桶限速，表现更平滑
调试建议：在 OpenStream() 后立即 stream.SetDeadline(time.Now().Add(3 * time.Second))，避免 goroutine 泄漏。
配置项里最容易被忽略的三个坑
多数人复制示例代码后直接跑通就结束，但线上压测常因这几个配置翻车：
-
yamux.Config.MaxStreamWindowSize：默认 65535 字节，但若服务端处理慢，客户端持续Write会卡住 —— 应根据业务单次消息大小设为 2–4 倍，比如日志推送设为 16384 -
smux.Config.Version：v1 协议不支持流优先级，v2 才有；但 v2 默认关闭，必须显式写Version: 2，否则无法利用反压机制 -
yamux.Config.EnableKeepAlive设为false时，NAT 网关 30 秒无流量会自动断连，且yamux不重连 —— 必须搭配应用层心跳或改用smux的KeepAliveInterval
真正麻烦的从来不是“怎么配”，而是“配完没压测，上线后流量一上来，流缓冲区吃光内存，进程 OOM 被系统 kill”。
