net包是操作系统网络栈的封装而非TCP/IP协议栈实现，所有网络操作最终通过系统调用交由内核处理，Go仅提供统一接口抽象（如net.Conn），协议行为（重传、滑动窗口、SYN发送等）完全由内核TCP栈决定。
net 包不是对 TCP/UDP 协议栈的“实现”，而是对操作系统网络栈的封装 —— Go 语言本身不重写 TCP/IP 协议栈，所有连接、监听、收发都最终调用 syscalls（如 socket、bind、connect、sendto、recvfrom）交由内核处理。
这意味着：你写的 net.Listen("tcp", ":8080") 不是在 Go 里建了个 TCP 状态机，而是在调用 socket(AF_INET, SOCK_STREAM, 0) + bind() + listen()；conn.Write() 实际触发的是 send() 系统调用，数据是否重传、滑动窗口怎么动、SYN 什么时候发 —— 全由 Linux/BSD 内核的 TCP 栈决定。
为什么不能绕过内核自己实现 TCP？
这不是 Go 的限制，而是现代操作系统的共识设计：
- 协议栈需处理大量边界情况（乱序、丢包、时钟漂移、路径 MTU 发现等），内核经过数十年打磨和生产验证
- 用户态实现无法直接访问网卡中断、无法高效轮询或使用
epoll/kqueue，性能会断崖式下跌 -
net.Conn接口抽象层本意就是隔离协议细节，让你专注业务逻辑，而非重造轮子
net.Dial 和 net.Listen 背后的真实行为差异
同一个函数名，TCP 和 UDP 的底层系统调用路径完全不同：
-
net.Dial("tcp", "host:port")→socket()+connect()（阻塞直到三次握手完成） -
net.Dial("udp", "host:port")→socket()+connect()（仅设置默认对端地址，不发任何包） -
net.Listen("tcp", ":port")→socket()+bind()+listen() -
net.ListenUDP("udp", addr)→socket()+bind()（无listen，UDP 没有“监听队列”概念）
注意：net.ListenUDP 返回的是 *UDPConn，它没有 Accept() 方法 —— 因为 UDP 不存在“连接接受”这回事。
粘包问题只在 TCP 场景出现，且与 Go 无关
所谓“粘包”，本质是 TCP 的字节流特性 + 应用层未定义消息边界导致的。Go 的 conn.Read() 只负责从内核 socket 缓冲区拷贝字节，它不关心你认为的“一条消息”该多长。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
立即学习“go语言免费学习笔记（深入）”；
- 发送端调用两次
conn.Write([]byte("hi"))，内核可能合并成一个 TCP 段发出 - 接收端一次
Read()可能读到多个“逻辑消息”，也可能只读到半个 - 解决方式永远是应用层协议设计：加长度头、分隔符（如
\n）、固定包长 —— 和 Go 无关，换 Python/Java 一样要处理
别指望 net.Conn 提供“按消息读取”方法；bufio.Scanner 或自定义 io.ReadCloser 封装才是正解。
UDP 的“连接感”是假象
很多初学者误以为 net.Dial("udp", ...) 建立了某种“UDP 连接”。其实它只是：
- 创建一个绑定了远端地址的
*UDPConn - 后续
Write()自动发给该地址（省去每次填WriteTo()） - 后续
Read()只接收来自该地址的数据（内核做了过滤）
但底层仍是无连接：没握手、没状态、没重传。如果对方宕机或防火墙拦截，你只会收到 read: connection refused（ICMP 目标不可达被内核转为 errno），而不是“连接断开事件”。
