UDP收包丢包主因是系统接收缓冲区过小且不可靠，需提前调大；receive()须在子线程阻塞调用并重置DatagramPacket length；服务端应作为权威校验落子并广播，客户端比对棋盘哈希、预提交显示；跨机通信需正确使用InetAddress，避免localhost；序列化宜用轻量文本或自定义二进制格式，禁用Java默认序列化。
UDP收包时为什么总丢子？——DatagramSocket的接收缓冲区和阻塞模型
Java的DatagramSocket默认使用操作系统级UDP接收缓冲区（通常仅几十KB），一旦客户端发包频率稍高或网络抖动，没来得及receive()的包就直接被内核丢弃，不会报错，也不会重传。这不是你代码写错了，是UDP本身的特性在“诚实”地甩锅。
- 用
socket.setReceiveBufferSize(65536)提前加大缓冲区（注意：必须在bind()前调用，否则无效） -
receive()是阻塞调用，别在UI线程里直接用；开单独线程轮询，每次receive()前重置DatagramPacket的length字段（否则第二次收包可能截断） - 服务端别用一个
DatagramPacket对象反复传给receive()——它会把新数据往旧buffer里写，导致粘包或覆盖
怎么让两个玩家知道谁该下？——用UDP实现简单状态同步而不是“实时对战”
别幻想用UDP模拟TCP那样的可靠顺序传输。五子棋不是FPS，不需要毫秒级同步。真正要解决的是“状态一致性”：双方棋盘必须始终一致，且落子权不能冲突。靠来回ACK、重传、序列号太重，也违背UDP轻量初衷。
- 服务端做唯一权威：所有落子请求都发给服务端，服务端校验合法性（是否轮到你、位置空、未终局），再广播给所有客户端
- 每个落子包带自增
moveId（long型时间戳+随机后缀足够）、当前棋盘哈希（如Arrays.hashCode(board)），客户端收到后比对哈希，不一致就主动向服务端拉全量棋盘 - 客户端本地只保留“预提交”状态：点下棋子后立刻显示半透明动画，但真正生效等服务端广播回来——避免网络延迟造成“我点了却没反应”的错觉
“对方已连接”却收不到包？——检查InetAddress构造和NAT穿透边界
本地测试用InetAddress.getByName("127.0.0.1")没问题，一放到两台真实机器上就失联，大概率是地址写死了"192.168.x.x"或误用了getLocalHost()返回了错误网卡地址。
- 服务端监听用
new InetSocketAddress(0)（端口0由系统分配）+DatagramSocket绑定new InetSocketAddress(0)，然后socket.getLocalPort()获取实际端口，再告诉客户端 - 客户端连接服务端时，
InetAddress必须是服务端对外可访问的IP（比如路由器分配的192.168.1.100），不是localhost也不是127.0.0.1 - 跨公网？UDP直连基本不可行。真要外网测试，先关掉双方防火墙，再确认路由器没开启SPI防火墙或UPnP关闭——否则你的
DatagramPacket根本出不了内网
序列化棋盘数据时踩了哪些坑？——别用ObjectOutputStream走UDP
有人直接把int[][] board塞进ObjectOutputStream再转byte[]发UDP，结果收端ClassNotFoundException或者长度超64KB被截断。UDP单包上限约64KB，而Java序列化带大量类名、字段描述等冗余信息，体积膨胀严重，还强耦合JVM版本。
立即学习“Java免费学习笔记（深入）”；
- 用纯文本协议最稳：例如
"MOVE,12345,player1,5,7,1"（类型、moveId、玩家名、x、y、棋子色），String.getBytes(StandardCharsets.UTF_8)编码，接收端new String(packet.getData(), 0, packet.getLength(), StandardCharsets.UTF_8)解码 - 如果追求紧凑，手写二进制格式：前4字节
int表示操作类型（1=落子，2=认输），后4字节int表示x，再4字节y，共12字节一包，体积可控，无兼容风险 - 永远校验
packet.getLength()——Wireshark抓包会发现UDP包头后可能有填充字节，packet.getData().length是buffer总长，不是有效数据长
UDP不保证送达，也不保证顺序，但五子棋的业务逻辑天然容错：只要服务端权威、客户端肯校验、序列化够轻量，丢一两个包顶多延迟半秒刷新，远不如一个没清零的DatagramPacket length 字段来得致命。
