游戏服务器通信层必须用net包直连TCPConn，因net/http带HTTP头、状态码等冗余开销，无法满足实时对战帧同步需求，且不支持心跳、断线检测、粘包处理；正确做法是net.Listen后conn.Read()读原始字节，辅助接口另起http.Server隔离。
net 包直连 TCP 是游戏服务器通信层的唯一可行路径，net/http 不能用于帧同步主链路——它自带 header 解析、连接复用、状态码逻辑，会直接卡死二进制协议包读取，且无法处理粘包、心跳、断线重连等基础能力。
为什么不能用 http.Server 接游戏客户端二进制包
常见错误现象：conn.Read() 卡住、连接超时断开、收到的数据长度不对、解包后 ID 或坐标完全错乱。
根本原因在于 http.Server 默认等待完整 HTTP 请求（含 method、path、headers、空行），而 Unity/Unreal 客户端发的是裸二进制帧，没有换行或冒号分隔，http.Serve 会一直阻塞在 bufio.Scanner 或内部 read loop 里。
正确做法是：只用 net.Listen("tcp", ":3000") + accept + conn.Read() 拿原始字节流；若需登录/配置等辅助接口，单独起一个 http.Server 绑定不同端口（如 :8080），和主游戏逻辑物理隔离。
GOOS/GOARCH 多平台交叉编译必须关 CGO
游戏服务器部署通常要求静态二进制，避免目标机器缺失 libc 或 musl 导致 ./server: not found 错误。
立即学习“go语言免费学习笔记（深入）”；
关键条件：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
-
CGO_ENABLED=0必须显式设为 0，否则go build会默认启用 CGO，链接动态库 -
GOOS=linux+GOARCH=amd64（或arm64）组合才真正生成目标平台可执行文件 -
-ldflags="-s -w"去除调试符号和 DWARF 信息，减小体积约 30%～50%
示例命令：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o server-linux-amd64 .
协议层条件编译：区分 Unity 客户端与调试工具
Unity 默认用小端序（binary.LittleEndian），但本地 CLI 调试工具可能用大端或文本协议，硬编码会导致解包失败。
推荐用 //go:build 标签做协议分支：
- 主协议包加
//go:build unity，导入encoding/binary并固定用binary.LittleEndian - 调试工具包加
//go:build cli，用json.Decoder或自定义文本解析 - 构建时指定：
go build -tags unity -o server-unity .
注意：//go:build 后必须空一行再写包声明，否则被忽略；同时要配 go mod tidy 清理未引用的依赖。
打包脚本里最容易漏掉的三件事
一键部署看似简单，但生产环境出问题往往卡在这几个点：
- 没清空旧服务残留进程：
killall -q server或systemctl stop xxx必须执行且检查返回值，否则新进程 bind 端口失败 - 上传后没
chmod +x：Linux 下无执行权限，Permission denied直接报错 - 没验证二进制兼容性：
file ./server-linux-amd64应输出ELF 64-bit LSB executable, x86-64，不是shared object
真正稳定的部署，不是“能跑起来”，而是每次上线前自动校验这三项。否则凌晨三点收到告警，第一反应不是查代码，而是翻 deploy.sh —— 那就说明它还不够可靠。
