@whoami9894 你还是没理解这里的问题到底在哪。

「假设我给个 1024 bytes 的 buffer，实际 packet 有 1400 bytes，ReadFrom 给我返回的一定是 1024。」
「我需要知道 length 才能调用 Read，你告诉我你调用 Read 就知道 length 了一样。」

如果知道 UDP 的原理，就根本不会出现用 1024-byte buffer 去读 1400-byte packet 这种情况，也不会需要在这个包头加一个 header 记录 body 的长度，更不会出现不合时宜的用 io.ReadFull 去读取 body 全文。

你前面其实也自己把这个问题总结出来了，「当不知道 UDP packet 长度时怎么分配 buffer 大小？」你这里给的答案是「分配一个足够大的 buffer，不需要像 stream 一样去做额外的上层分包」，但其实并没有真的回答问题：多大才是足够大？为什么不需要做分层？这两个问题都需要对 UDP 底层有基本的理解才能解释。这才是楼主的根本问题。

「 TCP 粘包」有与之互补的「 UDP 分段」版本了 https://www.v2ex.com/t/648023

@whoami9894 说白了，这个问题和本站之前出现的「 TCP 粘包问题」如出一辙：不去研究底层原理，一切全靠瞎猜。

@whoami9894 因为他的根本问题是他对 UDP 的基本原理不清楚，才会问出这么奇怪的问题。如果理解 UDP 的语义，自然就会知道不能分多次去读同一个包，也不会出现什么不知道包的长度还需要去读一个 header 来判断 body 长度的问题。举个例子，为什么 DNS over TCP 需要两个字节的头部而 DNS over UDP 不需要？因为 UDP 的包长度在接受的时候就是已知的，根本就不可能会使用 io.ReadFull 这个调用。你不去找他的根本问题在哪里，只给一个解决表面问题的答案，他也不会意识到自身的问题在哪里，以后继续犯类似的错误。

你觉得你听明白了问题？你自己说的「 不知道 UDP packet 长度时怎么分配 buffer 大？」你自己想想正确答案应该是啥。

@whoami9894 你又想说啥

@monkeyWie Excuse me? 给你指了方向不去想自己哪里没搞明白，解决问题全靠瞎猜？

瞎猜有什么用，UDP 协议基本特性都不知道，回去补习网络基础知识。

PacketConn 第一次返回的就是整个包的长度，你还要从哪里去找 body 的长度？

网络基础知识太差又不看文档，net.PacketConn.ReadFrom 返回值的第一个是啥？

@Ehco1996 了解，就是说轻量云是个完全独立的云

@11ssss 还没空做！可能需一个催更按钮的催更按钮😂

@mason961125 多谢多谢！😂

会有的会有的😂

@df4VW 放 redis 的话一致性问题怎么解决？当然要看具体场景对数据准确性和可用性的要求。

@Z1on 要变成全球催更系统了 😂

@haohello 看情况，不会差😂

@louieliu 最好都有😄