用time.ticker替代time.sleep可精准控帧，避免误差累积；关卡数据应预加载为结构体切片；方向键需处理转义序列，推荐golang.org/x/term；切换关卡时stop旧ticker并恢复终端状态防泄漏。
Go 里用 time.Ticker 控制游戏帧率，别直接 time.Sleep
贪吃蛇卡顿、加速不一致，八成是帧逻辑没和系统时钟对齐。用 time.Sleep 简单休眠会累积误差，尤其在多关卡切换后，速度越来越飘。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每关初始化一个
time.Ticker，周期设为time.Duration(1000 / fps) * time.Millisecond，比如第 1 关 10fps → 100ms，第 3 关 18fps → ~55ms - 主循环用
阻塞等待，而非 <code>time.Sleep，避免因逻辑耗时导致跳帧 - 关卡升级时，先
ticker.Stop()，再新建 ticker；不这么做会导致 goroutine 泄漏
关卡数据用结构体切片预加载，别在运行时拼接字符串
有人把地图写成多行字符串，每次重绘都 strings.Split + strings.Replace，既慢又难调试——特别是第 5 关加了障碍物后，控制台输出全是乱码。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 定义
type Level struct { Width, Height int; Obstacles []Point; FoodPos Point; Speed float64 } - 所有关卡数据在
init()或main()开头用字面量初始化，例如：levels = []Level{<br> {Width: 60, Height: 20, Obstacles: nil, FoodPos: Point{30,10}, Speed: 10},<br> {Width: 60, Height: 20, Obstacles: []Point{{10,5},{10,6},{10,7}}, Speed: 12},<br>} - 不推荐用 JSON 文件动态加载——命令行工具启动慢 200ms 以上，用户按
Enter后愣住半秒很破坏节奏
bufio.NewReader(os.Stdin) 读方向键要处理 \x1b[A 类转义序列
本地测试按方向键正常，一打包发给朋友就失灵：因为 Windows 的 cmd 和 macOS 的终端发送的“上箭头”根本不是单个字符，而是三字节序列（如 \x1b[A），直接 reader.ReadString('\n') 永远等不到回车。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
bufio.NewReader(os.Stdin)+reader.ReadRune()逐字符读，遇到0x1b就连续再读两字节，比对是否为[A、[B、[C、[D - Windows 下若仍异常，加一句
os.Stdin.WriteString("stty -icanon -echo")（需 cgo）太重，不如直接用golang.org/x/term的MakeRaw—— 它跨平台且无依赖 - 别忘了在程序退出前调用
term.Restore，否则用户终端会残留“输啥都不显示”的状态
goroutine 泄漏：关卡切换时旧渲染 goroutine 还在往 chan struct{} 发信号
玩到第 3 关突然 CPU 占 90%，pprof 一看十几个 goroutine 堵在 select { case renderCh —— 因为新关卡启了新 goroutine，但老的没收到退出通知，还在拼命发帧信号。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个关卡生命周期绑定一个
context.Context，渲染 goroutine 用select { case - 关卡切换时调用
cancel()，旧 goroutine 自然退出；不要靠close(renderCh)，那会 panic - 如果用了
sync.WaitGroup等待 goroutine 结束，务必在 cancel 后wg.Wait()，否则可能提前释放资源导致 segfault
多关卡真正的麻烦不在逻辑，而在状态清理——哪怕只漏掉一个 goroutine 或一个 timer，跑久一点就会卡死。检查方法很简单：每切换一次关卡，runtime.NumGoroutine() 打个日志，看它是不是稳定在个位数。
