QQ中国象棋源码揭秘：应对API大改的高频面试题

版本升级后 API 全变了，代码直接跑不通？这是很多老手转新手时最头疼的坑。别慌，这正是面试官最爱挖的【高频面试题】。

很多人以为 QQ 中国象棋只是个网页游戏，其实它背后是一套极致的实时同步算法。今天咱们不聊虚的，直接拆解它的核心逻辑。

入口定位：从前端到后端的链路

想搞懂原理，得先知道数据怎么流。QQ 中国象棋前端主要依赖腾讯的 qq-game-sdk，这是一个基于 WebAssembly 和 WebSocket 的高性能通信库。

关键路径拆解：

用户操作：点击棋盘，触发 onBoardClick 事件。
本地校验：前端先跑一遍规则引擎（Rule Engine），判断这一步是否合法。比如“马走日”、“象飞田”。
消息封装：将合法的操作打包成 Protobuf 消息，而非 JSON。为什么？因为 Protobuf 体积更小，解析更快。
WebSocket 推送：通过长连接发送到腾讯的 GameServer。
服务器仲裁：服务器收到消息后，再次校验，并广播给对手。

这里有个大坑： 很多初学者以为服务器只是转发数据，错了。服务器是唯一的状态真源。前端的状态可能因为网络延迟而不同步，必须以服务器下发的 GameSnapshot（游戏快照）为准。

核心片段：状态同步与冲突解决

QQ 中国象棋最核心的难点，不是画棋盘，而是状态同步。网络会有延迟，A 走了车，B 还没收到，这时候 B 也走了马，怎么办？

我们来看一段简化后的核心同步逻辑（伪代码，基于 TypeScript 风格）：

class ChessGameState {private board: number[][]; // 11x9 棋盘，0为空，1红子，2黑子，3+为具体棋子private lastServerSeq: number; // 服务器最后一次同步的序列号private localPendingMoves: Move[]; // 本地已发出但未确认的移动// 核心：应用服务器快照public applyServerSnapshot(snapshot: ServerSnapshot): void {// 1. 如果快照序号比本地旧，忽略（防止旧消息覆盖新状态）if (snapshot.seq <= this.lastServerSeq) {return;}// 2. 直接替换整个棋盘状态// 注意：这里不做增量合并，直接全量覆盖。// 因为象棋棋子少，全量同步的数据量远小于增量合并的计算开销this.board = snapshot.board.map(row => [...row]);this.lastServerSeq = snapshot.seq;// 3. 处理本地“未确认”的移动// 如果服务器已经包含了这个移动，从待办列表中移除this.localPendingMoves = this.localPendingMoves.filter(move => {const isApplied = this.isMoveInBoard(move);if (isApplied) {console.log(`Move ${move.id} confirmed by server`);return false;}// 如果服务器没包含，说明被服务器拒绝了（非法移动）// 或者还在队列中，需要重新排队console.warn(`Move ${move.id} pending or rejected`);return true;});// 4. 触发 UI 更新this.notifyUI();}// 辅助：检查移动是否已在棋盘中体现private isMoveInBoard(move: Move): boolean {// 简化逻辑：检查目标位置是否是该棋子// 实际项目中需要更复杂的哈希校验return this.board[move.toY][move.toX] === move.pieceId;}
}

逐行解析：

snapshot.seq <= this.lastServerSeq：序列号机制。这是解决网络乱序的关键。TCP 保证顺序，但 UDP 或 WebSocket 重传可能导致旧包后到。用序列号过滤掉旧状态，保证状态单调递增。
this.board = snapshot.board.map(row => [...row])：全量覆盖。有人问，为什么不用增量（Diff）？因为象棋只有 32 个棋子，11x9=99 个格子。传 99 个整数的开销，比计算“哪几个格子变了”再合并的 CPU 开销要小。在移动端，CPU 比带宽更贵。
localPendingMoves：乐观 UI 的核心。用户点了棋子，前端立即在 UI 上显示移动，不等服务器回复。这提升了体验。但如果服务器说“你这步非法”，前端就要回滚。这段代码就是处理回滚逻辑的。

设计思想：为什么是这套架构？

这套设计思想源自**“客户端预测 + 服务器权威”**（Client-Side Prediction + Server Authority）。

1. 为什么服务器权威？ 防止作弊。如果前端说了算，黑客可以改内存，直接让“兵”变成“车”。服务器必须拥有最终解释权。

2. 为什么客户端预测？ 为了手感。如果每走一步都等服务器确认（RTT 50ms），下棋会感觉“粘滞”。预测让 UI 立即响应，用户感觉不到网络延迟。

3. 数据结构的巧思： QQ 中国象棋的棋盘数据不是用对象数组，而是用扁平化的一维数组或位图（Bitmask）。

// 进阶技巧：用整数表示棋子
// 0: 空
// 1-6: 红方 帅仕相马车兵
// 7-12: 黑方 将士象马车卒// 优化：将 11x9 的棋盘压缩为一个 64 位整数（如果只用 6 位/子，其实不够，但可以用 BigInt 或多个 Int32）
// 这里展示一个更通用的技巧：用 Map 存储非空位置const boardMap = new Map<number, number>(); 
// Key: y * 9 + x (0-98)
// Value: pieceId// 序列化时，只遍历 Map，而不是遍历 99 个格子
function serializeBoard(boardMap: Map<number, number>): string {const entries = Array.from(boardMap.entries());return entries.map(([pos, piece]) => `${pos}:${piece}`).join(',');
}

避坑指南：

不要用 JSON 传输棋盘：JSON 解析慢，体积大。用 Protobuf 或自定义二进制协议。
不要在前端存完整历史：内存会爆。只存最近 10 步用于悔棋，更早的靠服务器日志。
处理断线重连：重连后，服务器会下发一个 SyncMessage，包含当前完整状态。前端收到后，直接 applyServerSnapshot，清空本地预测队列。

手写简化版：实现一个最小可行同步

假设我们要在本地模拟两个客户端，看看这个逻辑怎么跑。

// 模拟服务器
class MockServer {private currentSeq = 0;private board = Array(99).fill(0); // 初始空棋盘private clients = new Map<string, ChessGameState>();// 客户端发送移动请求async handleMove(clientId: string, move: Move): Promise<void> {// 1. 校验合法性（简化：只检查目标位置是否为空）const targetPos = move.toY * 9 + move.toX;if (this.board[targetPos] !== 0) {// 非法，发送拒绝消息this.sendToClient(clientId, { type: 'REJECT', moveId: move.id });return;}// 2. 应用移动const fromPos = move.fromY * 9 + move.fromX;this.board[targetPos] = this.board[fromPos];this.board[fromPos] = 0;this.currentSeq++;// 3. 广播给所有客户端const snapshot = {seq: this.currentSeq,board: [...this.board],move: move};for (const [id, state] of this.clients) {if (id !== clientId) {// 发给对手this.sendToClient(id, { type: 'SNAPSHOT', data: snapshot });}}// 发给发起者确认this.sendToClient(clientId, { type: 'CONFIRM', data: snapshot });}private sendToClient(id: string, msg: any) {const state = this.clients.get(id);if (state) {// 模拟网络延迟setTimeout(() => {if (msg.type === 'SNAPSHOT' || msg.type === 'CONFIRM') {state.applyServerSnapshot(msg.data);}}, 50 + Math.random() * 100); // 50-150ms 随机延迟}}
}

这段代码演示了：

服务器作为单一真源：所有状态变更都在 MockServer 中发生。
异步确认：客户端发送移动后，不会立即得到确认，而是通过 setTimeout 模拟网络延迟。
状态覆盖：客户端收到 SNAPSHOT 后，直接覆盖本地状态，保证了最终一致性。

面试加分点： 如果面试官问“如果两个客户端同时走了棋，怎么解决？” 答案：

时间戳仲裁：服务器收到两个移动，按时间戳先后顺序处理。
移动 ID 排序：如果时间戳相同（同一毫秒），按移动 ID 或用户 ID 排序。
结果：后到的移动可能被标记为“非法”或“过期”，服务器会下发一个包含最新状态的快照，让后到的客户端回滚。

应用场景：从象棋到通用实时系统

这套思路不只适用于象棋，几乎所有实时状态同步场景都能用：

在线文档协作（如 Google Docs）：
- 操作：插入字符、删除字符。
- 冲突：两人同时删同一个字符。
- 解决：操作变换（OT）或 CRDT。但核心思想一样：服务器权威，客户端预测。
多人游戏（FPS/RTS）：
- 象棋是回合制，简单。FPS 是实时制，更复杂。
- 需要状态插值（Interpolation）和外推（Extrapolation）来掩盖网络延迟。
- 但“服务器权威 + 客户端预测”是基础。
金融交易撮合：
- 订单是“移动”，成交是“服务器确认”。
- 必须保证原子性和一致性，比象棋更严格。