conn.write(mystruct)必然报错，因net.conn.write仅接受[]byte，而go结构体无法隐式转为字节切片；必须先序列化为[]byte并添加长度前缀（如4字节大端序）以解决tcp粘包问题。
Cursor 本身不生成或执行网络协议逻辑，它只帮你写、补全、解释 Go 代码；真正要让 net.Conn 支持自定义消息格式，你得自己定义序列化方式、加长度头、处理粘包——而 Cursor 的补全容易在这些关键点上“帮倒忙”。
为什么 conn.Write(myStruct) 必然报错
Go 的 net.Conn.Write 只接受 []byte，传结构体进去会直接编译失败：cannot use myStruct (type MyStruct) as type []byte。Cursor 在你光标停在空函数里按 Cmd+K 输入“发送结构体”时，可能默认给出 json.Marshal 后直接 Write 的代码——这能过编译，但线上必出粘包问题。
- 别信“先 Marshal 再 Write”就是完整方案：它只解决了序列化，没解决 TCP 流式导致的消息边界丢失
- Cursor 不会主动提醒你加长度前缀，也不会判断你是否用了
io.ReadFull - 如果用
fmt.Sprintf("%v", s)拼字符串再转[]byte，字段顺序、空值、时间格式全不可控，调试时你会怀疑人生
writePacket 和 readPacket 必须成对出现
可靠协议的最小闭环是「写端加长度头 + 读端按头读足」。Cursor 可以帮你写出其中一端，但大概率不会自动补全另一端，更不会保证两端字节序一致。
- 写包必须用
binary.BigEndian.PutUint32(header, uint32(len(payload)))：用int或小端序，跨平台或对接其他语言客户端时直接失败 - 读包必须用
io.ReadFull(conn, header[:])：裸调conn.Read(header)可能只读到 2 字节就返回，后续解析全乱 - 长度字段建议设上限（如
if length > 1024 * 1024），否则恶意构造大长度可触发 OOM，Cursor 的补全不会加这层防护
选 json 还是 gob？Cursor 不会替你权衡
Cursor 对序列化格式没有偏好，它只是按你描述生成代码。但生产环境里，选错格式会在上线后集中爆发。
-
gob是 Go 专属：Python/PHP 客户端根本解不开；结构体加字段或改类型，旧版本服务端一收包就 panic -
json表面简单，实际踩坑密集：time.Time默认序列化成带时区的字符串、浮点数精度丢失、nil字段和空字符串行为不一致 - 真正稳健的选择是
protobuf（强 schema、多语言、向后兼容）或msgpack（轻量、多语言），但 Cursor 不会自动帮你生成 .proto 文件或注册类型
最常被忽略的一点：协议设计不是写完 writePacket 就结束。你得手动验证两端是否严格对称——比如用 nc -l 8080 抓包看前 4 字节是不是预期长度，再确认 payload 能否被目标端完整还原。Cursor 不提供抓包或协议校验能力，它只管生成代码行，不管数据流是否真实通透。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
