accept()后读不到首消息因tcp流式特性及客户端未flush；轮流落子需服务端单线程处理请求并校验；客户端断连常因未等响应即关闭socket；斜线输赢判断须从落子点四向探查连续长度。
为什么 ServerSocket accept() 后立刻读不到客户端发来的第一个消息？
因为 TCP 是流式协议，accept() 只建立连接，不保证数据已到达；客户端可能还没 flush，或 Java 的 BufferedWriter / PrintWriter 默认缓冲未关。
- 服务端用
new BufferedReader(new InputStreamReader(socket.getInputStream()))读时，务必确认客户端发送后调用了flush()（PrintWriter构造时传true可自动 flush） - 避免混用
Scanner和BufferedReader读同一个 socket 流——它们内部缓冲不共享，极易丢数据 - 调试时在客户端发完消息后加
Thread.sleep(50)，能快速验证是不是纯时序问题（上线前必须删）
怎么让两个玩家轮流落子不乱序？
靠服务端单线程顺序处理请求最稳妥；别在每个 socket 线程里直接改棋盘——并发写 char[][] board 会覆盖对方操作。
- 所有落子请求统一走一个
BlockingQueue<move></move>，由单独的 gameLoop 线程消费并更新棋盘 -
Move类至少含playerId（1 或 2）、row、col，服务端收到后先校验是否轮到该玩家、位置是否空、是否已赢 - 校验通过才广播给两个客户端：用
ObjectOutputStream写new BoardUpdate(board, currentPlayer)，比拼字符串解析更稳
客户端连上就断，抓包看到 RST？
大概率是客户端 socket 写完没等响应就 close()，或服务端线程崩溃后没 clean up socket。
- 服务端每个 client handler 必须包 try-catch，并在 finally 块里显式
socket.close()、in.close()、out.close() - 客户端发完登录请求后，不要立刻
System.exit(0)；至少等一个in.readLine()回应（哪怕超时）再关 - Windows 上用
netstat -ano | findstr :8080查端口残留，Linux 用lsof -i :8080，避免“端口被占用”假象
五子棋输赢判断总漏判斜线？
只检查 (0,0)→(4,4) 这种固定偏移会漏掉从 (2,3) 开始的活五；得从落子点出发，沿四个方向（横、竖、正斜、反斜）各探 4 格。
立即学习“Java免费学习笔记（深入）”；
- 写个辅助方法
countInDirection(char[][] board, int r, int c, int dr, int dc, char player)，返回同色连续长度 - 调用四次：
countInDirection(..., 0, 1, ...)（右）、(1, 0)（下）、(1, 1)（右下）、(1, -1)（左下） - 任意一个方向返回 ≥5 就赢；注意数组越界要提前 break，别硬算到负索引
同步的关键不是“快”，是“所有状态变更都经同一把锁或队列”。哪怕每步多耗 10ms，也比两边各自渲染出不同棋盘强——而这点恰恰在本地测试时完全暴露不出来。
