为什么说 Go 做游戏服务器就有人皱眉？

沉默是金，总会发光

大家好，我是沉默

如果你在技术群里说一句：

"我们准备用 Go 写游戏服务器。"

大概率会收到这样的反应：

"游戏服务器不是用 C++ 吗？"

"大型游戏都是 C++ / Erlang 吧？"

很多资深开发者会本能地怀疑：

Go 真的适合做游戏服务器吗？

奇怪的是，在其他后端领域，Go 却几乎是"王炸级语言"。

比如：

Docker
Kubernetes
etcd
TiDB
NATS

这些支撑 云原生时代的核心基础设施，很多都是用 Go 写的。

但一到 游戏服务器领域，Go 却像一个"被忽视的优等生"。

为什么会这样？

答案很简单：

不是 Go 不适合游戏服务器，而是很多人对 Go 有三个误解。

**-**01-

游戏服务器技术的三次时代变迁

在聊 Go 之前，我们先看看游戏服务器技术的历史。

游戏后端技术，大致经历过 三次语言时代。

第一阶段：端游时代 ------ C++ 统治

早期大型网游几乎全部使用 C++ 。

典型代表：

魔兽世界
剑网 3
天堂

核心逻辑大概是这样：

scss 复制代码

class Player {    void HandleMove(Packet* pkt) {        m_x = pkt->x;        m_y = pkt->y;        BroadcastToAOI(pkt);    }};

优势很明显：

极致性能
内存控制能力强
网络模型成熟

但代价也非常真实：

很多游戏服务器 70% 的崩溃来自内存问题：

内存泄漏
野指针
double free

开发成本极高。

第二阶段：手游时代 ------ Java / C# 崛起

手游时代，很多团队开始使用：

Java
C#

例如一个简单购买接口：

python 复制代码

@PostMapping("/buyItem")public Response buyItem(BuyItemRequest req) {    player.setGold(player.getGold() - req.getPrice());    return Response.success();}

makefile 复制代码

优势：

GC 自动管理内存

开发效率高

生态成熟

但新的问题出现了：

GC 停顿。 

真实线上日志可能是这样：

20:00:32 Full GC 触发
20:00:33 STW 800ms
20:00:34 玩家大量掉线

对于 实时游戏服务器 来说：

几百毫秒的停顿就足以造成事故。

复制代码

第三阶段：页游与轻量服务 ------ Node.js 尝试

后来一些团队尝试 Node.js。

优点：

前后端统一 JavaScript

异步 IO 非常强

缺点也很明显：

单线程瓶颈

CPU 密集任务困难

框架生态逐渐停滞（如 Pomelo）

- 02-

Go 为什么迟迟没在游戏圈爆火？

问题来了：

游戏服务器本质就是 高并发网络服务。

而 Go 正是为这个场景设计的。

但为什么游戏行业却一直比较保守？

主要来自三个误解。

误解一：Go 是做微服务的，不适合游戏

很多人认为：

Go 适合做 Web API，不适合做游戏服务器。

其实游戏服务器本质就是：

长连接 + 高并发网络服务。

例如一个最简单的 TCP 服务器：

css 复制代码

listener, _ := net.Listen("tcp", ":8080")for {    conn, _ := listener.Accept()    go handleClient(conn)}

关键点只有一个：

goroutine

每个连接只占 几 KB 内存。

相比传统线程模型：

技术	并发成本
C++ 线程	MB 级
Java 线程	百 KB
Go goroutine	KB 级

所以在 连接规模 上：

Go 其实非常有优势。

误解二：Go 的 GC 会卡顿

很多人对 Go GC 的印象停留在十年前。

但 Go 的 GC 已经进化很多次：

Go 版本	GC 暂停
1.5 (2015)	10~100ms
1.8 (2017)	<1ms
1.22 (2024)	<100μs

也就是说：

Go 的 GC 停顿已经小到几乎可以忽略。

对于大部分游戏服务器来说：

完全可接受。

误解三：Go 没有成熟游戏框架

这一点其实是真的。

目前 Go 的游戏服务器框架确实不多，比如：

Leaf
Nano
Pitaya

相比之下：

其他生态更成熟，例如：

Skynet（C + Lua）
Akka（Scala）
Orleans（C#）

所以问题并不是：

Go 不适合。

而是：

生态还没形成规模。

- 03-

Go 写游戏服务器最容易踩的三个坑

很多团队尝试 Go 时，会踩几个典型坑。

坑一：Handler 阻塞

新手常见代码：

scss 复制代码

func HandleLogin(msg *LoginMsg) {    user := db.Query("SELECT ...")      http.Get("https://api.xxx")}

如果：

DB 查询慢
HTTP API 慢

整个请求链路都会卡住。

结果就是：

一个慢接口拖垮整个服务器。

坑二：并发锁问题

典型死锁代码：

css 复制代码

func Transfer(from, to *Player) {    from.Lock()    to.Lock()}

如果另一个 goroutine 反向锁：

css 复制代码

to.Lock()
from.Lock()

服务器就直接死锁。

坑三：goroutine 泄漏

例如：

go 复制代码

go func() {    <-neverClosedChan}()

这个 goroutine 会：

永远存在。

当数量积累到几十万时：

服务器内存会直接炸掉。

**-****04-**总结

最后，我们客观总结一下。

Go 的优势

goroutine 并发模型优秀
单二进制部署
云原生生态强
开发效率高

Go 的短板

游戏服务器框架少
行业案例少
社区规模小
工具链不完善

Go 在游戏服务器的真正问题

很多人以为：

Go 不适合游戏服务器。

但其实真实情况是：

Go 做游戏服务器不是技术问题，而是生态问题。

性能？

Go 1.22 的 GC 已经足够优秀。

并发？

goroutine 天然适合高并发。

部署？

比 Java 简单，比 C++ 安全。

真正缺的是三样东西：

成熟框架
生产案例
最佳实践

当 云原生架构 逐渐进入游戏行业时，Go 其实有一个很大的机会窗口。

问题只有一个：

谁会成为第一个大规模使用 Go 做游戏服务器的团队？

如果让你做一个 10 万在线玩家的游戏服务器，

你会选：

C++
Java
Go

为什么？

复制代码