联机对战：无后端的 P2P 实现
playground 是纯静态站点、没有后端，联机却仍然可行：用 WebRTC 在两个浏览器之间直接建立一条
RTCDataChannel，落子就通过这条点对点通道传输。唯一的难点是「建连接前两端要先交换一段连接描述」（信令），本页把这一步换成手动复制粘贴一段编码——于是连信令服务器都不需要。下面先看三种联机架构的取舍。
1 · 三种联机架构
| 方案 | 数据怎么走 | 要不要后端 | 取舍 |
|---|---|---|---|
| WebSocket + 权威服务器 | 两端都连服务器，由它中转 / 托管对局状态 | 要 （持续运行） | 最稳定、天然穿透 NAT、好做防作弊；但要自建并运维后端。绝大多数在线对战这么做。 |
| WebRTC P2P + 信令服务器 | 浏览器直连传数据；服务器只用来交换信令 | 要一个轻量信令服务 (+ STUN/TURN) | 延迟低、省服务器带宽；信令服务很小，但 NAT 受限时仍需 TURN 中继兜底。 |
| WebRTC P2P + 手动信令 ← 本页 | 浏览器直连；信令那一步改成手动复制粘贴 | 零后端 | 真正无服务器，适合 demo / 小范围对局；代价是建连需手动交换一次，且无 TURN 时对称 NAT 可能连不上。 |
怎么连上（流程）：主持方点「创建邀请码」生成一段 offer 编码 → 把它发给对方（任意渠道均可）→ 对方粘贴后生成 answer 编码发回来 → 主持方粘贴并完成连接。通道一开，落子就直接在两个浏览器间点对点传。本机自测：把本页开两个标签页，一个当主持、一个当加入，在两个标签间互相复制那两段码即可。
连接失败的常见原因：本页只配了公共 STUN（帮双方发现自己的公网地址），没有 TURN 中继。当两端处在对称型 NAT（部分公司 / 校园网）后面时，纯 STUN 打洞会失败——生产环境通常再加一台 TURN 服务器兜底（那就又回到「需要一点后端」了）。同一局域网或多数家庭网络下，手动信令的纯 STUN 方案可直接连通。